What is streaming text to speech?

Streaming TTS
Streaming text to speech generates and plays audio as the words arrive rather than waiting for a complete sentence, so a reply can begin speaking while the rest is still being produced.

What Streaming TTS means in practice

The non-streaming version waits for the full text, synthesises it, then plays it. Simple, and it adds the whole generation time to the silence.

Streaming overlaps the two. Audio for the first few words plays while the rest is still being written.

That can remove a large part of the perceived delay, which is why nearly every voice product now works this way.

The trade is prosody. A system that has not seen the end of a sentence cannot shape the whole sentence's intonation, so long streamed replies drift slightly flat.

What people get wrong

One 30-word reply, two ways

Say a caller asks whether Thursday works, and the assistant's reply will be 30 words long. The timings here are illustrative and don't describe any particular product.

Without streaming, the system waits for the language model to finish writing all 30 words, perhaps 1.5 seconds. Then it turns the whole text into audio, which takes another half second. The caller hears two seconds of nothing, then the full reply.

With streaming, the first clause, Sure, let me look at Thursday, goes to the speech engine as soon as it's written. The caller hears a voice after about half a second, while the model is still writing the rest.

Where the text gets cut matters. Send the engine a chunk ending in St. and it has to guess between street and saint without seeing the next word. Hand it $1,250 split across two chunks and it may read one dollar, then two hundred fifty. Careful systems cut at commas and periods, and hold numbers and abbreviations until they're whole.

What gets thrown away when a caller cuts in

Streaming creates a bookkeeping problem that older systems never had. At any moment there are three versions of the reply. There's the text the model has written, the audio that's been generated, and the audio the caller has heard. When a caller interrupts, those three are different lengths.

Say the model wrote: We have 2:00 or 4:30 on Thursday, and I can also check Friday. The caller cuts in after 2:00 with, two's fine. She never heard 4:30 or Friday. If the system's memory of the conversation includes the full sentence, it may later act as though she turned those options down.

Two questions for a vendor follow from that. Does the transcript show what was spoken aloud, or what was written? After an interruption, does the assistant know where it was cut off?

You can test it yourself. Interrupt a long reply early, then ask what the other options were.

How GreetKeeper handles it

GreetKeeper makes no published claim about its audio pipeline timing, because none of it has been benchmarked to a standard we would print.

What matters on a real call is whether the rhythm feels right, and that is a judgment for your ears on a demo.

Short, direct replies help more than any technique. You write what the assistant says, so that lever is yours.

Streaming speech questions

Does streaming hurt the voice quality?

Slightly, on long sentences, because intonation is planned with less context. On short replies the difference is hard to hear.

Is it why some assistants feel faster?

Often, yes. Two systems taking the same total time feel very different depending on when audio starts.

Can I tell from the outside?

Listen for whether the reply starts crisply then continues, or arrives all at once after a pause. The second pattern is usually non-streaming.

Hear it take one of your calls

Two minutes, your own scenario, no card.