Live Stream Translation Latency Benchmark 2026
Measured numbers, full methodology, raw data, and the limitations — because as of publication, nobody in this space has published a real latency benchmark. So we did.
Published July 21, 2026 · Measurements taken July 21, 2026 · By the StreamTranslate engineering team
In our measurements, streaming speech recognition produced on-screen interim text with no measurable processing lag behind speech, locked final transcripts a median of 0.79 s after a phrase ended, and machine translation added a median of 241 ms. Typical end-to-end time for a locked, translated subtitle: ≈1 second, with 90th-percentile outliers around 2.5 s.
Why this benchmark exists
Every tool in the live captioning and translation space makes a latency claim — "real-time," "minimal lag," "under X seconds" — and none of them, including us until today, published measurements behind the claim. This page is our attempt to fix that: real numbers, the exact method used to get them, and an open invitation to every other vendor to publish theirs the same way.
Results
Stage 1 — Streaming speech-to-text (Deepgram nova-3, our production model)
| Metric | n | Median | p90 | What it means for a viewer |
|---|---|---|---|---|
| Interim results (text appearing as you speak) | 25 | ≈0 ms processing lag | ≈0 ms | Live text keeps pace with speech; the delay a viewer perceives comes from phrase chunking, not processing. |
| Final results (locked transcript after a phrase ends) | 8 | 790 ms | 2,065 ms | The corrected, final version of a caption lands well under a second after you stop talking, in the typical case. |
Stage 2 — Machine translation (English → Spanish, production racer endpoint)
| Provider | n | Median | p90 | Notes |
|---|---|---|---|---|
| Google translation endpoint (tier-1 racer in our provider race) | 10 phrases | 241 ms | 427 ms | Measured from a neutral US cloud network. Our production servers race multiple providers and take the first response, so production translation latency is at or below this figure. |
End-to-end (what a viewer experiences)
| Path | Composition | Typical (median) | p90 |
|---|---|---|---|
| Live text path (interim + translate + deliver) | ≈0 ms + 241 ms + delivery | ≈0.3 s behind speech | ≈0.5 s |
| Locked subtitle path (final + translate + deliver) | 790 ms + 241 ms + delivery | ≈1.0–1.1 s after phrase end | ≈2.5 s |
How this compares to other tools
Honestly: it can't be compared head-to-head yet, because no other vendor in this space has published measured latency figures. Here is the state of public claims as of July 2026:
| Tool | Architecture | Published latency data | Public claim |
|---|---|---|---|
| StreamTranslate | Cloud STT + provider-race translation, browser-source overlay | Yes — this page | Under 2 s (supported by measurement above) |
| LocalVocal (OBS plugin) | Local Whisper-class model on the streamer's own PC; CTranslate2/M2M100 for translation | None published | "Minimal lag" — varies with GPU/CPU and model size chosen; the machine is simultaneously encoding video |
| Maestra | Cloud transcription suite with live captioning tools | None published | "Real-time" |
| Akkadu | Cloud live captions | None published | "Real-time" |
| LiveTL | Human volunteer translators in chat | N/A | Human-speed (typically several seconds, quality can exceed machines) |
If you are one of these vendors and you publish measured figures with comparable methodology, we will link them from this page. Standing offer.
Methodology
- Speech-to-text: real human speech (28 s of natural talking-head audio, 16 kHz mono PCM) streamed to Deepgram's live websocket API (
nova-3, our production model) in 100 ms chunks at exact real-time pace. - Latency definition: for every transcript event, latency = wall-clock arrival time minus the stream-position of the end of the audio that the transcript covers. This is the standard streaming-STT latency measure — it cannot be gamed by buffering.
- Translation: ten streamer-typical English phrases ("That was insane, did you see that play?" etc.) translated to Spanish via the same Google endpoint our production race uses; median and p90 of timed calls reported.
- Environment: neutral US cloud machine — not our production servers, and not colocated with any provider. Production infrastructure is faster than this, not slower.
Limitations (read these before citing us)
- Single speaker, single language pair (EN→ES), one 28-second sample. Final-transcript sample size is small (n=8 phrase finals). We will re-run with more speakers, languages, and longer sessions and update this page.
- Competitor tools were not measured — there is no way to measure a local plugin fairly without standardizing hardware, and no cloud competitor publishes an equivalent endpoint methodology. Their rows above reflect their own public claims only.
- The p90 final-transcript latency (≈2.1 s STT alone) shows that outlier phrases can exceed our own "under 2 seconds" typical-case claim. We publish that number anyway; a benchmark that hides its worst numbers isn't a benchmark.
- Overlay delivery time is estimated, not measured, in this run.
Raw results
Interim STT latencies (ms, n=25): median −3, max +3 — i.e., within measurement noise of zero processing lag. Final STT latencies (ms, n=8): median 790, p90 2,065, max 2,065. Translation EN→ES (ms, n=10): median 241, p90 427. Measurements taken 2026-07-21.
