Proposal
Add PocketTTS (Kyutai Labs) as a TTS engine option in OmniVoice, alongside the quality engines (omnivoice, IndexTTS, Supertonic-3, etc.).
Why: latency (the interesting part)
The standout is latency. PocketTTS is purpose-built for it:
- 100M parameters (vs OmniVoice's multi-GB resident model).
- ~200ms to the first audio chunk, with streaming.
- ~6x real-time on a MacBook Air M4 CPU (2 cores, no GPU).
- Runs entirely on CPU, so zero VRAM contention.
For latency-sensitive or low-resource scenarios (notifications, reaction-triggered voice, real-time feedback, CPU-only / edge devices) this fills a gap none of the current engines hit: near-instant, lightweight TTS where "good enough, very fast" beats "excellent, slow and heavy." It is the complementary opposite end of the spectrum from the resident OmniVoice model.
Real-world signal: a two-way routing we already run
We (a downstream user) already run a custom two-way routing between OmniVoice and PocketTTS in our agents: OmniVoice for quality when latency is not critical and the GPU is free, PocketTTS for speed when low latency matters or the GPU is contended or unavailable. This is a production workaround for exactly the latency + resource gap, not hypothetical. Natively supporting PocketTTS as an OmniVoice engine would let this routing live in OmniVoice's engine picker (one process, one config, the existing engine-routing + GPU-preflight machinery) instead of a bespoke agent-level shim, and would benefit every user with the same latency/resource tradeoff.
Left to the maintainer's evaluation
This is a proposal, not a request to merge anything. The call on whether to add it is entirely yours:
- Languages: PocketTTS currently covers 6 (en/fr/de/pt/it/es) vs OmniVoice's 600+, so it is a narrower but much faster niche.
- Quality: voice cloning + streaming, but a 100M model will not match the heavy engines on expressiveness.
- License / fit / maintenance: a Kyutai Labs project (paper, model card); license and dep-pin compatibility are for the repo to decide.
Happy to provide measured latency/quality numbers from our setup, or sketch what an integration would look like (likely a SubprocessBackend sidecar given the dep profile), if useful. Flagging the use case + the latency angle + the existing demand (our two-way routing) as the signal.
Context: related to the recent omnivoice-subprocess engine (#1292) and the GPU-pool slot fixes (#1298), which made OmniVoice reliable under sustained use. Reliability does not address the latency gap for fast/lightweight CPU renders, which is the niche PocketTTS would fill.
Proposal
Add PocketTTS (Kyutai Labs) as a TTS engine option in OmniVoice, alongside the quality engines (omnivoice, IndexTTS, Supertonic-3, etc.).
Why: latency (the interesting part)
The standout is latency. PocketTTS is purpose-built for it:
For latency-sensitive or low-resource scenarios (notifications, reaction-triggered voice, real-time feedback, CPU-only / edge devices) this fills a gap none of the current engines hit: near-instant, lightweight TTS where "good enough, very fast" beats "excellent, slow and heavy." It is the complementary opposite end of the spectrum from the resident OmniVoice model.
Real-world signal: a two-way routing we already run
We (a downstream user) already run a custom two-way routing between OmniVoice and PocketTTS in our agents: OmniVoice for quality when latency is not critical and the GPU is free, PocketTTS for speed when low latency matters or the GPU is contended or unavailable. This is a production workaround for exactly the latency + resource gap, not hypothetical. Natively supporting PocketTTS as an OmniVoice engine would let this routing live in OmniVoice's engine picker (one process, one config, the existing engine-routing + GPU-preflight machinery) instead of a bespoke agent-level shim, and would benefit every user with the same latency/resource tradeoff.
Left to the maintainer's evaluation
This is a proposal, not a request to merge anything. The call on whether to add it is entirely yours:
Happy to provide measured latency/quality numbers from our setup, or sketch what an integration would look like (likely a
SubprocessBackendsidecar given the dep profile), if useful. Flagging the use case + the latency angle + the existing demand (our two-way routing) as the signal.Context: related to the recent
omnivoice-subprocessengine (#1292) and the GPU-pool slot fixes (#1298), which made OmniVoice reliable under sustained use. Reliability does not address the latency gap for fast/lightweight CPU renders, which is the niche PocketTTS would fill.