First-packet latency is the number that decides how your voice product feels

Most teams building a voice feature start by measuring the wrong thing. They generate a sentence, time the whole request, and record a number like "1.4 seconds". Then they ship it, and users say the product feels slow — even though 1.4 seconds sounds fast on paper.

The mismatch comes from a simple fact: people do not perceive total synthesis time. They perceive silence.

What the user is actually timing

When someone finishes speaking to a voice agent, an internal clock starts. It stops the instant they hear something back. Everything that happens after the first audio reaches their ear — the remaining 90% of the sentence being synthesised, buffered, and played — is invisible to that clock, because by then they are already listening.

This is why two systems with identical total synthesis time can feel completely different:

• System A takes 1.4s to produce the full sentence, then starts playing. Perceived wait: 1.4s.
• System B emits the first audio chunk at 90ms and streams the rest while playing. Perceived wait: 90ms.

Same workload. Same total compute. One feels broken, the other feels immediate.

The metric that separates them is time to first packet — how long after you send text does the first playable audio chunk come back. It is the only latency number that maps onto what a human actually experiences.

Why non-streaming APIs cannot fix this

A request/response TTS endpoint has a structural problem: it cannot return anything until it has everything. The response body is one audio file, and an audio file is not valid until it is complete. So the floor on perceived latency is the full synthesis time, no matter how fast your model is.

Making the model faster helps, but it fights the wrong constraint. Halving synthesis time from 1.4s to 0.7s is a large engineering effort for a wait that is still clearly audible. Streaming the same 1.4s of synthesis removes almost all of the perceived wait without touching model speed at all.

This is why MiraEcho exposes synthesis over WebSocket rather than only as a file endpoint. Audio is emitted chunk by chunk as it is generated. On the Flash tier, the first packet comes back in under 100 milliseconds — below the threshold where most listeners register a gap at all.

The part people get wrong: playback must keep up

Streaming solves the start of the problem and introduces a new one at the end. If your synthesis produces audio slower than real time, the player will drain its buffer mid-sentence and stutter. A stutter halfway through a word is worse than a clean 1.4s wait, because it reads as a malfunction rather than as thinking.

So a streaming implementation needs two properties, not one:

1. Low time to first packet — so playback can start early.
2. Generation faster than playback — so the buffer never runs dry once it has started.

The second is what lets you start playing at 90ms and still finish a thirty-second passage without a gap. When you evaluate a streaming TTS provider, measure both. A provider that wins on first-packet latency but generates slower than real time will sound worse than a slower one that never stutters.

A practical way to check: synthesise a long passage, log the arrival timestamp of every chunk, and compare the cumulative audio duration received against wall-clock time elapsed. If the audio-duration curve stays above the wall-clock line, you have headroom. If they converge, you are one network hiccup away from a stutter.

Where this matters most

The gap between total time and first-packet time widens as output gets longer, so the payoff scales with how much your product speaks:

• Conversational agents and call automation — every turn pays the latency cost, so it compounds across a conversation. This is where streaming is not optional.
• Live narration and interactive apps — the user is watching something happen; silence reads as a freeze.
• Batch narration for video or audiobooks — here total throughput genuinely does matter more than first-packet latency, because nobody is waiting in real time. Optimise for a different number.

That last case is worth stating explicitly, because the right metric depends on whether a human is waiting. If you are rendering a two-hour audiobook overnight, first-packet latency is irrelevant and you should be measuring cost per hour of audio instead.

What to take away

Measure time to first packet, not total synthesis time, for anything a person is waiting on. Then check that generation outruns playback so the early start does not turn into a stutter. Those two numbers, together, predict how a voice product feels far better than any single throughput figure.

If you want to see where your current setup lands, MiraEcho's streaming synthesis is free to start — send a request, log the chunk timestamps, and compare against whatever you are using now.