fix(flux): TTS round trip sent MP3, which Flux cannot decode - #15
Merged
Conversation
Caught live-probing the deploy, not by the suite. POST /api/tts-transcribe with mode=streaming and a flux-* model returned: Deepgram closed the stream immediately without transcribing (received 1005 (no status received [internal])) Cause: the round trip generates MP3 and lets Deepgram sniff the container. That is correct on /v1/listen and is why no `encoding` is sent to STT. But Flux's accepted list is linear16/linear32/mulaw/alaw/opus/ogg-opus — MP3 is not on it, and /v2/listen answers an undecodable stream by closing the socket rather than by saying so. Measured, same clip, encoding/sample_rate omitted, paced at 1x: mp3 -> 1005 close, nothing transcribed opus / ogg -> transcribed So the round trip now picks the CONTAINER by which endpoint will read it: Ogg-Opus for Flux, MP3 everywhere else. It still sends no `encoding` param to STT, so the constraint that comment protects is intact — the fix is upstream of it, in what gets generated. Batch is deliberately untouched: a flux model on /v1/listen returns V2_MODEL_ON_V1_LISTEN_ENDPOINT, which already says exactly what is wrong. Why the suite missed it: nothing mocked can discover that MP3 is undecodable by a model whose docs do not list its accepted containers next to the TTS encodings. Only the live round trip shows it, which is the argument for probing the deployment rather than trusting a green pipeline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by live-probing the #14 deploy, not by the suite.
POST /api/tts-transcribewithmode=streamingand aflux-*model returned:Cause
The round trip generates MP3 and deliberately sends no
encodingto STT so Deepgram sniffs the container. That is correct on/v1/listen. But Flux accepts onlylinear16/linear32/mulaw/alaw/opus/ogg-opus— MP3 is not on the list, and/v2/listenanswers an undecodable stream by closing the socket rather than saying so.Measured, same clip,
encoding/sample_rateomitted, paced at 1x:mp3opus(Ogg)Fix
Pick the container by which endpoint will read it: Ogg-Opus for Flux, MP3 everywhere else. Still no
encodingparam to STT, so the constraint that load-bearing comment protects is intact — this change is upstream of it, in what gets generated.Batch is deliberately untouched: a flux model on
/v1/listenreturnsV2_MODEL_ON_V1_LISTEN_ENDPOINT, which already says exactly what is wrong.Why the suite missed it
Nothing mocked can discover that MP3 is undecodable by a model whose docs list neither its accepted containers alongside the TTS encodings nor any error for the mismatch. Only the live round trip shows it. Three tests now pin the container choice and assert the round trip still never sends an STT
encoding.166 passed, 1 skipped.