Repository navigation
feat: fish audio tts ttfb - #2356
Conversation
Add a top-level flush_mode config with three modes. first_chunk (the default) flushes once after the first non-empty text chunk, off never sends a protocol-level flush, and every_sentence flushes when a chunk ends with a sentence terminator (. ? ! 。 ？ ！), matching the elevenlabs per_sentence_flush behavior. flush_mode is read from params in update_params() and removed from params so it is never merged into the vendor start request body. Invalid values raise ValueError listing the allowed modes. The final chunk (text_input_end) is followed by stop, which already flushes server-side, so it skips the flush. Blank text never flushes. The reconnect and get() replay paths apply the same rules. Also fix the mocked-client tests to invoke the on_text_send callback, correct a mock signature, and drop a redundant CancelledError re-raise so the extension lints at 10.00/10.
Add a regression test asserting the real FishAudioTTSClient fires on_text_send immediately before each text payload is written to the socket. The mocked-client tests replace the client entirely, so nothing exercised this callback. When the TTFB anchor moved to text-send time, those mocks silently kept their old shape and the tests stopped covering the audio_start and TTFB events, failing only on their assertions. This test pins the contract the extension relies on.
Log an error when the first audio chunk arrives without a text-send timestamp. In that state tts_audio_start, the TTFB metric, and the audio frame metadata registered by audio_start are all dropped with no signal at all, so the degradation is invisible from the outside. The extension always wires on_text_send, so this branch should never run in production; the log is there to make a future regression loud. Also tighten the mocked-client test helper so a dropped on_text_send fails with a clear contract message instead of a misleading "Did not receive tts_audio_start" assertion, keep the dump test double consistent, and cover the new log with a unit test.
|
[P1] Stop reconnecting after a completed vendor session After receiving [P2] Avoid replaying text whose audio has already been emitted If the socket drops after the first PCM chunks, reconnect unconditionally resends every entry in [P2] Preserve errors carried by the vendor's finish event Fish Audio reports synthesis failure with [P2] Exercise the real client's required reconnect ownership cases The reconnect test replaces [P2] Add the required exact audio-end accounting assertions tests/test_request_completion.py:50 The updated suite uses real clock values and only asserts that |
|
[P2] Preserve the pending stop flag across reconnects For a final input, [P2] Keep user text out of vendor diagnostic logs Every [P2] Select the response-header log in the observability test tests/test_observability.py:122 The normal The five findings in the earlier review also remain unresolved at |
adbe0c1 to
5f274ee
Compare
|
[P1] Retire completed sessions before handling the socket close After queuing [P2] Prevent full-text replay after audio has been emitted When a connection drops during synthesis after some PCM has reached TEN, this loop replays every saved text chunk without checking [P2] Preserve synthesis errors reported in the finish reason The documented failure response is [P2] Keep the retry budget across repeated receive failures The reconnect counter resets as soon as the handshake and replay sends succeed. If the upstream repeatedly accepts those sends and then closes before audio or [P2] Exercise the real client's required reconnect ownership cases The reconnect test replaces [P2] Add exact audio-end duration and interval assertions tests/test_request_completion.py:41 The updated suite uses the real clock and only checks that the event interval is nonnegative. It has no controlled-clock assertion distinguishing the audio-start/end interval from text-send latency, and no partial-audio-then-error case asserting exact emitted PCM duration; the flush test still permits a 10 ms discrepancy. The TTS test baseline requires exact coverage for success, partial error, interruption, and no-audio termination. Use known PCM and controlled clocks to assert both fields, including a zero interval when no audio-start event was emitted. |
No description provided.