fix(cartesia): stop sending max_buffer_delay_ms on /tts/bytes - #2442
Open
brodie-avoca wants to merge 1 commit into
Open
fix(cartesia): stop sending max_buffer_delay_ms on /tts/bytes#2442brodie-avoca wants to merge 1 commit into
brodie-avoca wants to merge 1 commit into
Conversation
8 tasks
🦋 Changeset detectedLatest commit: a4a4f56 The changes in this PR will be included in the next version bump. This PR includes changesets to release 38 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
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
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.
Description
toCartesiaOptionsputsmax_buffer_delay_ms: 0in the shared payload, so it goes out on/tts/bytesas well as the websocket. Cartesia rejects every non-streaming request with:#1107 added the field for the websocket message ("Add max_buffer_delay_ms = 0 to ws msg"); the placement made it apply to both paths. The main caller of
synthesize()in a voice pipeline is the TTSFallbackAdapterrecovery probe, so once a session fails over from Cartesia it can never recover to it. We observed one failover followed by 99 consecutive rejected recovery probes on a production call.Parity: the Python plugin only adds
max_buffer_delay_msin the websocket sentence stream (tts.py#L433-L434) and never sends it on/tts/bytes(tts.py#L366).Changes Made
max_buffer_delay_ms: 0under the existingstreamingguard intoCartesiaOptions, next toadd_timestamps.node:httpornode:httpsfrom the base URL protocol inChunkedStream(the port calculation already did), so the non-streaming path can be tested against a local plain-HTTP server the same way the websocket tests already are./tts/bytespayload has nomax_buffer_delay_ms; websocket packets still carry it.Pre-Review Checklist
Testing
restaurant_agent.ts/realtime_agent.ts: n/a, not a major changeAdditional Notes
The same handler never checks the response status, which is why this 400 showed up as silent empty audio rather than an error. That is a separate fix in #2443, which is stacked on this branch and should be reviewed after this one.