Latency budget for live-streaming translation — where the 0.5–1.0 second delay comes from

The first question most technical streamers ask about live translation is “what’s the latency?” The honest answer is “between 350 milliseconds and one second, depending on language pair, content complexity, and audio quality.” For most streaming contexts that’s invisible — well below the threshold where viewers notice a delay. For a few specific contexts it’s the binding constraint.

This article breaks down where the latency comes from, which streaming use cases tolerate which thresholds, and what you can do when latency matters more than translation quality. It’s the technical companion to the pillar article for streamers who care about the numbers.

Where the latency comes from

The end-to-end latency budget breaks into three stages of the translation pipeline, plus two network legs:

Network ingress (~50–100 ms). Audio travels from your microphone, through your computer’s audio system, over WebRTC to the LiveKit SFU, and from there to the translation agent. On a stable internet connection this is typically under 100ms. On a flaky connection or with a transcontinental geographic route, it can spike.

Speech-to-text (~200–400 ms). Deepgram Nova-3 streams partial transcripts as audio arrives — it does not wait for a complete sentence. The 200–400ms figure is the time from the speaker pronouncing a word to the recognition engine emitting a stable transcript of that word. For monosyllabic words this can be faster; for words that require disambiguation against later context (homophones, partial proper nouns), the engine may revise its output after additional context arrives.

Machine translation (~50–300 ms). The translation stage depends on which engine path your plan uses. Free tier uses Google Cloud NMT which is fast (~50–150ms per fragment). Paid tiers use a DualModelTranslator that routes to Translation LLM for major pairs (~100–300ms per fragment) for higher quality on idiom-heavy and context-sensitive text. The trade-off: NMT is faster, LLM is more natural-sounding.

Text-to-speech (~100–200 ms). Google Cloud TTS generates a natural-sounding waveform from the translated text. The synthesis time scales roughly linearly with output sentence length — short sentences are fast, long sentences take longer. Streaming TTS partial output keeps perceived latency lower than the per-utterance synthesis time would suggest.

Network egress (~50–100 ms). Translated audio travels from the LiveKit SFU back to the listener’s browser or phone. Same range as ingress, depending on the listener’s connection.

End-to-end on a stable connection: 450ms (best case, free tier, short utterance) to 1100ms (paid tier with LLM translation, long contextual sentence, mediocre network). The typical observed range for everyday content is 500–800ms.

For the full pipeline architecture, see how real-time speech translation works.

What 0.5–1.0 seconds feels like in practice

Sub-second latency is not the same as zero latency. Listeners can perceive it if they’re actively comparing — for example, watching the streamer’s lips on video while listening to the translated audio. For audio-only listening (the dominant pattern with Loquira), the 0.5–1.0 second delay is below the perceptual threshold for “this feels slow.”

A few comparison points:

• Studio video dub for film/TV typically uses 50–100ms re-alignment with lip movement. A consumer can detect the delay if they’re looking for it, but pop culture has trained audiences to tolerate even the 200–500ms lip-sync delay common in low-budget dub work.
• Simultaneous interpretation at conferences runs at roughly 3–6 seconds behind the speaker — interpreters need to hear an utterance before they can interpret it. International conference audiences are habituated to this delay.
• Live broadcast television runs at 5–15 second delay end-to-end (capture → encode → satellite → decode). Live sports broadcasts run at the lower end of that range; entertainment runs at the higher end with built-in profanity-delay buffers.

Loquira’s 0.5–1.0 second sits well below the conference interpretation baseline and well below the broadcast TV baseline. The reference point for “this feels delayed” for most listeners is the simultaneous interpretation baseline, and Loquira is faster than that.

Use cases by latency tolerance

Different streaming contexts have different latency tolerances. Roughly:

Latency-indifferent (any delay below 2s is fine):

• Long-form interviews, podcasts, monologue content.
• Tutorials and instruction where the listener is following along, not reacting in real-time.
• Story-telling streams, lore content, watch-along commentary.
• Church services, pastoral content, conference keynotes.

For these, the 0.5–1.0 second delay is completely invisible. The listener experiences a smooth, continuous translated track. No accommodation needed in the creator’s flow.

Latency-sensitive (notice but tolerate):

• Live Q&A sessions where international viewers want to ask questions in their own language and have them answered.
• Reaction streams where the streamer is reacting to videos / clips and the listener wants to follow the reactions.
• Live tech support / language tutoring where back-and-forth conversation matters.

For these, the 0.5–1.0 second delay is perceptible but doesn’t break the experience. The listener notices that the translation lags slightly, but the interaction still works. The main accommodation: when reading translated questions from chat, pause slightly longer between question and answer than you would on an English-only stream — this gives the translated-track listener time to catch up.

Latency-critical (binding constraint):

• Competitive game callouts where two players are coordinating in real-time across languages.
• Live performance / music where the audio is the timing reference (concerts, music streams).
• Sub-second-coordinated dual streams where two streamers are reacting to each other.

For these, the translation latency is too high to be a real-time companion. Translated-track viewers can still watch and engage, but they won’t be able to participate in the time-coupled portion of the stream. For competitive game callouts specifically, the consensus from streamers who have tried is: live translation is great for watch-along commentary but not for ranked-play competition. The fix is to scope the use case — translated tracks for the talk portion of the stream, not the competitive portion.

What you can do when latency matters

If your content type sits in the latency-critical bucket, a few options to consider:

1. Accept the limitation and design around it. The most common approach. Use live translation for the storytelling, commentary, and discussion segments of your stream; accept that the competitive segments are English-only for now. Most streamers find this is the right tradeoff.

2. Pre-stream summary or recap segment. For competitive play, schedule a 5–10 minute pre-stream segment where you describe what the stream will cover, in English (with translation). The international audience gets briefed on the context, then watches the competitive portion without translation. Post-stream, schedule another 5–10 minute recap segment with translation. This sandwiches the latency-critical content between latency-indifferent context.

3. Lower the translation quality bar in exchange for speed. Loquira’s free tier uses NMT which is faster than the LLM-based paid path. For latency-sensitive contexts, the free tier or a paid-tier setting tuned for speed-over-quality is a real option. The translated track will sound less natural but arrive 100–200ms sooner. The pricing model article discusses which tier choices affect translation behavior.

4. Mute the translation during the latency-critical portion. Loquira sessions can be paused mid-stream. For competitive segments specifically, pausing the translation track and resuming it when the segment ends keeps your translated-track viewers from hearing a mid-game audio dropout that doesn’t make sense to them.

Latency vs translation quality is a real trade-off

It’s worth being explicit: there is a real trade-off between latency and translation quality, and the right choice depends on your content. Higher-quality LLM-based translation is naturally slower. Lower-quality NMT-based translation is naturally faster. There is no engineering trick that produces both maximum quality and minimum latency simultaneously.

For most creator content (the latency-indifferent bucket), the LLM path is the right choice — the extra 100–200ms is invisible and the translation quality improvement is meaningful. For competitive callout-driven content (the latency-critical bucket), the NMT path may be the right choice if you go this route at all.

For the architecture-level explanation of where the latency comes from and why it can’t be much lower without sacrificing quality, see how real-time speech translation works.

What about future improvements?

Translation latency has been on a sustained downward trend since 2022 — every six to twelve months, the pipeline gets ~100–200ms faster across the stack. Speech recognition models stream more aggressively; translation models run on faster hardware; TTS models produce streaming output sooner. The 0.5–1.0 second range as of mid-2026 was 1.5–3.0 seconds in 2022.

Continued improvement is reasonable to expect but not guaranteed. The fundamental floor — the speed of light through the network plus the minimum time to process meaningful linguistic context — is probably around 200–300ms. The pipeline is currently 2–3x that floor.

For now, the practical assumption: live translation operates at 0.5–1.0 second latency. Design your content around that, and the rest of the experience works.

---

Want to try it? Start a free session — speak in any of 49 languages, your audience hears in 225. No setup, no credit card.