Simba 3.2 time to first audio on Coval: 379 ms to 106 ms, same model
Coval's independent benchmark measured Simba 3.2's median time to first audio at 379 ms on 13 September 2026 and 106 ms on 24 September, with the same model. What changed, why Coval counts leading silence, and how to reproduce it.

On 13 September 2026, Coval’s independent TTS benchmark measured SpeechifyAI’s Simba 3.2 at a median time to first audio of 379 ms. Over the 24 hours to 24 September it measured 106 ms, and Simba 3.0 went from 469 ms to 102 ms (our reviewed Coval snapshot). The model did not change: same weights, no distillation, no quantization. Voices and prices did not change either, and customers changed no code.
A second harness agrees: Voice Arena’s US English board read Simba 3.2 at 123 ms on 24 September, the lowest time to first audio of the 14 models it measures there (our reviewed Voice Arena snapshot).
Why Coval measures the full stack
Coval publishes its harness as open source and runs it against every provider on a fixed schedule, every 30 minutes. It does not isolate the model: a request travels from Coval’s runner to the provider’s API and back, through whatever sits in front of the model, the way a customer’s request does.
That choice matters for voice agents. A caller does not experience a model, they experience the whole path, and a benchmark that scores only the model hides everything between the caller and the GPU.
What Coval counts: the first audible sample
Coval’s methodology defines time to first audio as:
TTFA = (first audio chunk arrival − synthesis start) + leading silence inside the stream before the first audible sample
The leading silence is found by an RMS-threshold onset detector on the assembled audio (methodology). So a provider that sends its first byte quickly, but opens the stream with silence, gets no credit for the silence. The caller hears nothing until the first word, and Coval’s number says so.
What the metric exposed in ours
On 14 September we shipped a new serving build for Simba 3.2. Coval’s median barely moved, from 379 ms to 368 ms, and the reason was in its leading-silence column: the new build had started to open its streams with silence, and Coval’s median leading silence went from 21 ms to 102 ms. Take the silence out and the rest of the median fell from about 358 ms to 266 ms, so the build was faster, and the silence gave most of it back (snapshot).
Coval TTS benchmark, Simba 3.2
Coval counts from the request to the first audible sample, so silence at the start of the stream is part of the number. Daily medians, then the 24 hours to 24 Sep 2026.
- 13 Sep379 ms · 21 ms silence
- 14 Sep368 ms · 102 ms silence
- No runs recorded 15 to 17 Sep
- 18 Sep116 ms · 10 ms silence
- 19 Sep122 ms · 13 ms silence
- 20 Sep107 ms · 13 ms silence
- 24 h to 24 Sep106 ms · silence not reported
Bars are drawn to one scale, 0 to 400 ms. The two medians are read separately, so the solid part is the TTFA median minus the silence median, not a separately measured round trip; Coval did not report silence for the last 24 hours, so that bar is the total alone, not zero silence. Every figure: our reviewed Coval snapshot.
We fixed the silence rather than argue with the metric: by 18 September the median leading silence was 10 ms, and it read 10 to 13 ms through 20 September (snapshot). The chart shows the two changes together: the bar shortens, and the hatched silence at its end shrinks to a sliver.
What we changed, and what we did not
This section is our own account of the engineering; what it did is in Coval’s and Voice Arena’s numbers, linked throughout.
The model stayed the same. Simba 3.2 and Simba 3.0 run the same weights as before the change, with no distillation, no quantization and no smaller variant to buy speed, so what you hear is what you heard before.
What changed is everything around the model:
- A new serving build on a different GPU class, with work in the inference stack: graph capture instead of per-request setup, compiled stages, and a scheduler that emits audio sooner.
- Admission checks from cache. Plan, entitlement and rate-limit checks used to be live lookups in front of the first byte. They now resolve once per request from a last-known-good cache.
- The serving path beside the GPUs, on connections that stay warm between requests instead of a new handshake each time.
- The extra silence removed. Coval’s median leading silence went from 102 ms on 14 September to 10 to 13 ms from 18 September, below the 21 ms of 13 September (snapshot).
None of it needed anything from customers. Every streaming request to Simba 3.2 and Simba 3.0 takes the faster path automatically, because one US East serving path serves every request to the API (latency guide), and prices are unchanged at $10 per million characters on Starter, $8 on Pro and $6 on Scale.
A second, independent reading
Voice Arena measures time to first audio on its own runner, with its own client and texts. On 24 September 2026 its US English board read Simba 3.2 at a median of 123 ms, ahead of Inworld’s Realtime TTS 2 Research Preview at 168.5 ms and Gradium’s TTS at 236 ms, the lowest of the 14 models it measures for latency there (snapshot). On the same board Simba 3.2’s quality rank is 7 of 20, with a rank range of 6 to 8.
The two harnesses do not report the same number, and they should not: each measures from its own place, with its own voices and texts. What they agree on is the shape: in their 24 September 2026 readings, Simba 3.2 reached the first audible sample in a little over 100 ms on both Coval and Voice Arena (Coval snapshot, Voice Arena snapshot).
How this compares with our own number
Our own dashboards measure something else: the first byte leaving our edge. On 15 September 2026, Simba 3.2’s production first byte in US East was 56 ms at the median and 102 ms at the 90th percentile. Coval and Voice Arena add the network between their runner and our API, their own client, and any silence before the first audible sample, so their numbers read higher, and they are the ones closer to what a caller hears. The latency guide explains how to measure both from where your users are.
How evaluation design changes what gets optimized
A provider optimizes what gets scored. When the score is time to first byte, the cheapest way to improve it is to send something early, and what gets sent does not have to be audible. When the score is the first audible sample, the only way to improve it is to make the caller hear the first word sooner.
Coval’s choice made one of our regressions visible within a day, from outside, on a public board. That is the benchmark doing its job, and it is why we would rather be measured this way.
Reproduce it
- Coval’s harness: github.com/coval-ai/benchmarks, with the methodology and the live results at benchmarks.coval.ai/tts.
- Voice Arena’s board: voicearena.com/tts-leaderboard/us-english.
- The numbers in this post: the Coval snapshot and the Voice Arena snapshot, as read on the dates shown. Live boards move; the snapshots do not.
- Your own measurement: stream a request and time the first audible sample, as the latency guide shows.
Create a free API key and hear the first word for yourself.
Common questions
What is Simba 3.2's time to first audio?
What is perceived time to first audio?
Did Speechify change the model to make Simba 3.2 faster?
Why do Coval and Voice Arena report different latencies for Simba 3.2?
Does the faster Simba 3.2 cost more or need a code change?
This post is narrated by Harper on Simba 3.2 through our text to speech API. How the player works: add read-aloud to your docs and turn speech marks into captions.