perf(tts): pipeline sync per-sentence synthesis with playback

[MahdiHedhli]

What does this PR do?

Removes the per-sentence dead air from voice-mode / wake-word replies for every provider without a chunked streaming API.

stream_tts_to_speaker's universal sync fallback ran strictly serially per sentence — synthesize, play, and only then start synthesizing the next sentence — so every sentence boundary added a full synthesis-time of silence. The chunked streamers (elevenlabs/openai/gemini/xai) already avoid this; edge, piper, and plugin providers all paid it on every reply. For local model providers the cost dominates the conversation: at real-time-factor ≈ 1, the reply is silent between sentences for about as long as it speaks.

This replaces the serial _speak_via_sync with _SyncSentencePipeline: one single-threaded synthesis worker (sentences stay FIFO — providers never see concurrent calls from this loop, same effective concurrency as before) feeding one playback worker through a small bounded queue. While sentence n plays, sentence n+1 is already synthesizing.

Behavior preserved deliberately:

• Ordering — single synth worker + single playback worker, both FIFO.
• stop_event — short-circuits both stages; queued items are skipped, not played.
• Failure isolation — one sentence's synthesis failure doesn't kill the reply.
• Temp-file hygiene — always unlinked, including on stop/failure.
• tts_done_event semantics — the finally block flushes the pipeline before the event fires, so continuous voice mode never reopens the mic over its own voice.
• Testability — synthesize/play are resolved late (module global / import in worker), so the existing monkeypatch-based tests pass unchanged.

Related Issue

No open issue found — searched open+merged PRs and issues for sentence/pipeline/TTS-latency phrasings per CONTRIBUTING's search-first rule; closest prior art is the chunked-streamer work this composes with (streamer path untouched).

Type of Change

• ⚡ Performance and robustness (category 4 in the contribution priorities)

Changes Made

• tools/tts_tool.py — add module-level _SyncSentencePipeline; construct it in stream_tts_to_speaker when no chunked streamer resolves; route _speak_sentence's sync branch through it; retire the serial _speak_via_sync; flush the pipeline in finally before tts_done_event.set().
• tests/tools/test_tts_streaming.py — 4 new tests: timestamp-proven overlap (synth of sentence 2 starts before playback of sentence 1 ends), order preservation + per-sentence failure isolation, stop-event skipping queued playback, temp-file cleanup.

How to Test

1. pytest tests/tools/test_tts_streaming.py -q — 34 pass here (the pre-existing test_streamer_path_writes_pcm_to_output failure on macOS is unrelated: the Darwin TCC guard forces output_stream = None, so that test can only pass on Linux CI).
2. Neighboring suites (test_tts_streaming_e2e.py, test_voice_mode.py, test_tts_speed.py, test_tts_plugin_dispatch.py): 193 passed / 8 failed — the identical 8 (WSL2/PowerShell) fail on unpatched main on macOS; zero regressions.
3. Real-world timing, real synthesis (OmniVoice plugin provider on Apple Silicon — a local model at RTF ≈ 1.2), same 3-sentence reply, playback simulated at the produced clips' exact durations, serial vs pipelined interleaved best-of-2 under identical load:

	serial (main)	pipelined (this PR)
time to first word	10.8 s	4.4 s
mid-reply silence	11.2 s	1.8 s (second gap 0.03 s)
full-reply wall	33.2 s	17.0 s

Fast cloud providers benefit less in absolute terms but the boundary stall (network round-trip per sentence) still disappears behind playback.

Checklist

• Tests pass locally (see platform caveats above)
• I've tested on my platform: macOS 15 (Apple Silicon), Python 3.11
• Documentation — N/A (internal path; behavior contract of stream_tts_to_speaker unchanged)
• cli-config.yaml.example — N/A (no new config keys)
• Cross-platform: pure stdlib threading (ThreadPoolExecutor, queue, threading) — no platform-specific code; Windows/macOS/Linux identical
• Tool descriptions/schemas — N/A

[teknium1]

Thanks for the focused performance improvement. The premise is confirmed on current main: tools/tts_tool.py:3437-3440 selects the sync fallback, and _speak_via_sync at tools/tts_tool.py:3479-3485 completes synthesis and playback serially. PR commit 77d20942d3b3913464b2f86e8e9ab3aa1254e690 replaces that branch with a bounded single-synthesis-worker/single-playback-worker FIFO pipeline and flushes it before the done event.

No verified correctness or design-fit problems found in the reviewed diff. The production file has not changed since the PR base; only older tests were pruned from tests/tools/test_tts_streaming.py, so salvage should be largely mechanical.

This is an automated hermes-sweeper review.

[kshitijk4poor]

Thanks @MahdiHedhli — the measurement was right and the gap is real: main's prefetch rework covers only chunked streamers, so edge/piper/plugin providers still paid full per-sentence dead air on the serial sync path. Salvaged into #77355 with your authorship preserved via cherry-pick; conflict resolution kept all of main's prefetch machinery intact, and the ordering/backpressure/shutdown semantics of your pipeline passed a dedicated audit (single-worker FIFO + bounded queue + drain-then-shutdown close, running before tts_done_event.set). 245 tts tests green. Closing in favor of the salvage.