TTS Service

What it is. TTS Service (Doubling Technologies TTS, "DTTTS") is a production text-to-speech API I built for speed without giving up quality. The marketing page leads with the numbers that matter: 73 ms time-to-first-byte, 54 voices, 5 models, 24 kHz output, and an ElevenLabs-compatible interface. The pitch is honest about the tradeoff — "CosyVoice3 for quality, Kokoro for speed, or let the hybrid engine give you both."

What it does. One API fronts several TTS engines — CosyVoice3, Kokoro, and Qwen3-TTS — behind virtual model aliases, so a client asks for a voice and the service picks the right engine underneath. Since it mirrors the ElevenLabs surface, the familiar controls all work: the playground exposes stability, similarity, style, speed, and a speaker-boost toggle, plus format selection down to MP3 44.1 kHz 128 kbps. Voices come in two flavors — voices designed from a text prompt ("a warm, friendly male voice with…") and cloned voices — both managed in a Voices library and a Voice Workshop, and bound to a quality or optimized model per voice. At the time of capture the live instance had served 140K requests across 15.7M characters at a 0% error rate.

The interesting engineering. The heart of it is hybrid streaming over a CUDA job queue: a real-time operational status bar shows queue depth (0/10) and the dashboard charts request volume, average TTFB, and average latency over time, including per-model TTFB/latency scatter plots with outlier exclusion so a cold start doesn't skew the picture. An admin "Remote Engines" panel lets me attach GPU backends, and the whole thing builds as GPU/CPU/ROCm Docker variants with benchmarking scripts (bench-model.sh kokoro --streaming) baked in so latency claims are measured, not guessed.

Stack: Python TTS core with CUDA GPU workers, CosyVoice3 / Kokoro / Qwen3-TTS engines, hybrid streaming, an ElevenLabs-compatible HTTP/WebSocket API, and a React admin UI. Tracked in Orchestrator as TTS Service (repo yolanother/ttsservice).

Links: tts.jaxns.net