Latency

On 9 Oct 2026, timed from a client in US East over warm connections, SpeechifyAI’s simba-3.2 reached first audible audio in a median (p50) of 47 ms over the WebSocket input stream and 64 ms over the HTTP stream, the lowest of the 13 endpoints we timed from US East that day. From Zurich it was not the lowest: ElevenLabs Flash v2.5 over HTTP reached first audible audio in 142 ms, against 145 ms for our WebSocket input stream and 153 ms for our HTTP stream. First audible audio is the wait a listener hears, timed by our own open script to the first audible sound in the decoded audio. Our server-side first byte on the HTTP stream, 56 ms p50 and 102 ms p90 on production traffic on 15 Sep 2026, is lower than that stream’s 64 ms because it stops inside our API, before the network between you and US East and before any silence at the start of the audio. The method, every endpoint’s numbers, where other providers were faster, every request and the script are in the round’s write-up. This page explains what each number counts, what adds to the wait on your side, and how to measure it from where your code runs.

Measured numbers

Every row is simba-3.2, and every value is a measured percentile, not a guarantee. The first-audible rows come from our 9 Oct 2026 round, which timed 13 streaming endpoints from six providers with one open script; the first-byte row comes from production customer traffic.

First byte, first audible audio, total generation time

Generated speech can begin with a short silence, and its length varies with the voice and the text. In the 9 Oct 2026 round, simba-3.2 opened with a median of 10 ms of silence, and no endpoint we timed opened with less, from either place. On POST /v1/audio/speech, time to first byte and total generation time are the same, because the response is sent once the whole clip exists.

How we measure

Both measurements report percentiles, not averages: p50 is the median request, and p90 is the request slower than 9 in 10. A few slow outliers move an average, not a median.

First audible audio: our 9 Oct 2026 round

• Where from. Two Google Cloud VMs at the same time, one in us-east4-a in Ashburn, Virginia, and one in europe-west6-a in Zurich.
• What was timed. 13 streaming endpoints from six providers, each reading the same 12 sentences of 76 to 102 characters as 24 kHz 16-bit mono PCM, from one Python client, in a shuffled order so every provider shared each minute. simba-3.2 spoke with the voice geffen_32.
• When the clock stops. At the first 10 ms window of decoded audio whose RMS level passes -45 dBFS: the first audio chunk’s arrival plus the silence before that window, or the arrival of the chunk carrying it if that is later.
• Warm and cold. The figures above come from 60 requests per endpoint over one kept-open connection, after 2 discarded warm-up requests. With a new connection opened inside the clock, 12 requests per endpoint, simba-3.2 read 74 ms over the WebSocket input stream and 75 ms over the HTTP stream from US East.
• Everything else. Every endpoint’s tables, warm and cold, every column where another provider was faster, every request and the script to rerun it are in the round’s write-up.

First byte: production traffic

• What is timed. Every production request to POST /v1/audio/stream records, inside our API, the time from admitting the request (after authentication and rate limits) to writing the first audio byte to the response.
• Which requests. Successful streaming requests from real customer traffic, not a synthetic test, split by model. The figures above were read from that traffic on 15 Sep 2026. They cover every text and voice our customers sent, so they do not compare one to one with the round’s 12 sentences.
• Where. Our US East serving path, which served every request to api.speechify.ai in September 2026. The clock stops when the first byte leaves our API, so the network between you and US East, the handshakes of a new connection, silence at the start of the audio and your player’s buffer are all outside it.

Independent measurements

Two benchmarks we do not run also time simba-3.2, from their own runners to the first audible sample. Coval measured a 109 ms median time to first audio over the 24 hours to 9 Oct 2026 11:00 UTC, and Voice Arena read 123 ms p50 for its “Simba 3.2 Real-time” row on its US English board on 16 Oct 2026. Both sit above the 56 ms first byte because they include the network between their runner and US East and any silence at the start of the audio, which our first byte does not count. Each is that benchmark’s own reading on that date, not our measurement, and the boards change as they re-run. Our low-latency TTS guide links the reviewed, dated snapshot behind each figure.

What adds latency on your side, and how to cut it

Measure it yourself

Time the first chunk of a streaming response from where your code runs, and read the Server-Timing header on the same response. Its ttfb is our share of that request’s wait, from the request reaching our API to the first audio byte, and model is the model’s own time to first audio. Your first-chunk time minus ttfb is the network and your own stack. ttfb starts slightly earlier than the published server-side first byte, so it also counts authentication and rate limiting. The first chunk is the first byte, so the examples below stop the clock before any silence at the start of the audio. To count that silence, find the first audible 10 ms window in the decoded PCM. The loop in the round’s write-up does that at 1% of full scale (-40 dBFS); to match the round’s -45 dBFS threshold, use its script.

For a fair number:

• Discard the first request or two. They include opening the connection.
• Vary the text between requests, as your real traffic does.
• Send requests one after another. A request beyond your plan’s concurrency limit returns 429, not a slower response.
• Take at least 20 requests and report p50 and p90, not the average or the single best run.
• Measure with PCM. With Ogg, the first bytes are header pages, not audio.

# pip install httpx
import os
import re
import statistics
import time
import httpx
# One client for every request, so the connection is reused.
client = httpx.Client(
    base_url="https://api.speechify.ai",
    headers={"Authorization": f"Bearer {os.environ['SPEECHIFY_API_KEY']}"},
    timeout=30.0,
)
def measure(text: str) -> tuple[float, float, str]:
    start = time.perf_counter()
    first_chunk_ms = None
    with client.stream(
        "POST",
        "/v1/audio/stream",
        headers={"Accept": "audio/pcm"},
        json={"input": text, "voice_id": "geffen_32", "model": "simba-3.2"},
    ) as response:
        response.raise_for_status()
        for _ in response.iter_raw():
            if first_chunk_ms is None:
                first_chunk_ms = (time.perf_counter() - start) * 1000
    total_ms = (time.perf_counter() - start) * 1000
    match = re.search(r"ttfb;dur=([\d.]+)", response.headers.get("server-timing", ""))
    if first_chunk_ms is None:
        first_chunk_ms = total_ms
    return first_chunk_ms, total_ms, match.group(1) if match else "n/a"
for n in range(2):
    measure(f"Opening the connection, request {n}.")  # not counted
first_chunks = []
for n in range(20):
    first_chunk_ms, total_ms, server_ttfb = measure(
        f"Your order {1000 + n} shipped this morning and arrives on Thursday."
    )
    first_chunks.append(first_chunk_ms)
    print(f"first chunk {first_chunk_ms:.0f} ms, server ttfb {server_ttfb} ms, total {total_ms:.0f} ms")
deciles = statistics.quantiles(first_chunks, n=10)
print(f"first chunk p50 {deciles[4]:.0f} ms, p90 {deciles[8]:.0f} ms")

FAQ

Related