Can a prompt replace PlayHT?

Build a local streaming text-to-speech server with a latency budget you can measure.

Model: run an open-weights TTS model locally — Piper for speed and small footprint, or Kokoro for better quality at higher cost. Make the model a swappable module behind one interface and ship both, downloaded on first use.

Streaming endpoint: POST text, receive audio as a chunked HTTP stream, first chunk emitted as soon as the first sentence is synthesised rather than after the whole input. Split incoming text on sentence boundaries and synthesise sentence by sentence into a queue, so a long paragraph starts playing immediately. Support both raw PCM and Opus output; Opus for anything crossing a network.

Latency instrumentation, which is the point of this build: measure and expose time to first audio byte, real-time factor (audio seconds produced per wall-clock second), and queue depth. Log every request with those three numbers. Provide a benchmark command that fires N concurrent requests and prints the distribution, so the user can see exactly where their machine stops keeping up. Do not hide these numbers behind a debug flag — they are the reason to run this rather than call an API.

Voices: expose the model's built-in voices with speed and pitch controls, and a pronunciation dictionary the user maintains for names and jargon the model gets wrong. Ship no cloned voices and no celebrity or public-figure voices, and refuse to load a voice model that does not come with a documented licence — state this in the README.

Caching: hash the text plus voice plus settings and cache the rendered audio on disk, so repeated phrases (a greeting, an error message) return instantly. For an agent workload this is where the real latency win comes from.

Out of scope: voice cloning, any hosted or multi-tenant deployment, an account system, and a timeline or editing interface. This is a server, not a studio.