what is tts latency?
what is tts latency?
what is tts latency?
text to speech (tts) latency is the delay between sending text to a voice model and receiving its speech. the number changes according to the endpoint. time to first byte (ttfb), time to first audio (ttfa), and playback start stop the clock at different moments.
what do ttfb and ttfa measure?
time to first byte measures the time from sending the request to receiving the first response byte. that byte may contain a header or audio-container data rather than speech.
ttfa measures the time from sending the request to receiving the first chunk of synthesized audio. unlike ttfb, it waits for audio rather than any response byte. the audio may still need decoding or buffering before playback.
measurement | clock stops when |
|---|---|
ttfb | the first response byte arrives |
ttfa | the first synthesized audio chunk arrives |
playback start | the listener hears the first sound |
in this article, all three measurements start when the request is sent. only the endpoint changes. check each benchmark's measurement boundaries before comparing results.
tts latency example
a streaming tts request could produce this timeline:
0 ms Request sent 120 ms First response byte arrives 170 ms First audio chunk arrives 230 ms Playback begins
0 ms Request sent 120 ms First response byte arrives 170 ms First audio chunk arrives 230 ms Playback begins
the ttfb is 120 ms and the ttfa is 170 ms. the listener waits 230 ms before hearing speech.
the space between ttfa and playback comes from the receiving application. an mp3 or opus stream needs decoding. the player may also hold a small buffer to prevent gaps when later audio arrives.
ttfb vs ttfa and full response time
ttfb shows when the server starts responding. ttfa shows when generated audio reaches the application. playback start shows when that audio reaches the listener.
none of these numbers measures a complete voice-agent response. before tts begins, the system has to detect the end of the caller's turn and generate a reply. network delivery, audio decoding, and playback follow synthesis. a voice agent with 200 ms ttfa can still leave a caller waiting much longer than 200 ms.
full-file latency measures how long the entire recording takes to arrive. that matters for a voice over while streamed speech depends more on how quickly playback can begin and whether it continues without gaps.
why does tts latency matter for voice agents?
long pauses can make a live call feel broken. ttfa measures the delay until the application receives the first audio chunk, including processing and network time. playback start adds any decoding and buffering delay, while the full conversational pause also includes turn detection and reply generation.
rumik's mulberry 1.5 latency benchmark reported about 162 ms ttfb at roughly five concurrent requests. the test used one h100 gpu, prompts of about 15 to 25 words, and the same output format and sample rate across providers.
text to speech (tts) latency is the delay between sending text to a voice model and receiving its speech. the number changes according to the endpoint. time to first byte (ttfb), time to first audio (ttfa), and playback start stop the clock at different moments.
what do ttfb and ttfa measure?
time to first byte measures the time from sending the request to receiving the first response byte. that byte may contain a header or audio-container data rather than speech.
ttfa measures the time from sending the request to receiving the first chunk of synthesized audio. unlike ttfb, it waits for audio rather than any response byte. the audio may still need decoding or buffering before playback.
measurement | clock stops when |
|---|---|
ttfb | the first response byte arrives |
ttfa | the first synthesized audio chunk arrives |
playback start | the listener hears the first sound |
in this article, all three measurements start when the request is sent. only the endpoint changes. check each benchmark's measurement boundaries before comparing results.
tts latency example
a streaming tts request could produce this timeline:
0 ms Request sent 120 ms First response byte arrives 170 ms First audio chunk arrives 230 ms Playback begins
the ttfb is 120 ms and the ttfa is 170 ms. the listener waits 230 ms before hearing speech.
the space between ttfa and playback comes from the receiving application. an mp3 or opus stream needs decoding. the player may also hold a small buffer to prevent gaps when later audio arrives.
ttfb vs ttfa and full response time
ttfb shows when the server starts responding. ttfa shows when generated audio reaches the application. playback start shows when that audio reaches the listener.
none of these numbers measures a complete voice-agent response. before tts begins, the system has to detect the end of the caller's turn and generate a reply. network delivery, audio decoding, and playback follow synthesis. a voice agent with 200 ms ttfa can still leave a caller waiting much longer than 200 ms.
full-file latency measures how long the entire recording takes to arrive. that matters for a voice over while streamed speech depends more on how quickly playback can begin and whether it continues without gaps.
why does tts latency matter for voice agents?
long pauses can make a live call feel broken. ttfa measures the delay until the application receives the first audio chunk, including processing and network time. playback start adds any decoding and buffering delay, while the full conversational pause also includes turn detection and reply generation.
rumik's mulberry 1.5 latency benchmark reported about 162 ms ttfb at roughly five concurrent requests. the test used one h100 gpu, prompts of about 15 to 25 words, and the same output format and sample rate across providers.
related terms
related terms
related terms