What "Real-Time" Translation Actually Means

"Real-time" translation is not instant, and no product sold today makes it instant. What the phrase describes is a delay short enough that two people can keep taking turns without the conversation collapsing. Between the moment you finish a thought and the moment the other person hears it, a system has to capture your audio, decide you've stopped talking, recognise the words, translate them, synthesise new speech, and play it back. Each of those stages costs time. Google's research team, describing the streaming model behind live translation in Meet and on the Pixel 10, says a standard two-second delay is typically used for real-time conversations, and notes that older cascaded systems commonly ran 4 to 5 seconds. That is the honest range. Anything advertised well below it is almost certainly measuring one segment of the pipeline rather than the whole thing.

I sell translation earbuds and a browser translation app, so I have an obvious interest in this number. That's exactly why I'd rather explain how the delay is built than quote a figure at you. Once you can name the stages, you can tell which stage a vendor's number came from, and you can measure the one that actually matters yourself in about ninety seconds.

What does a translation system do between you speaking and hearing?

The work is a pipeline. Even the newest end-to-end models still perform these functions internally; they just fuse the steps rather than handing text between separate services.

Here is the full budget, microphone to ear. I've deliberately left the millisecond column out, because for most consumer products the per-stage figures are simply not published, and inventing them would defeat the point of the exercise.

Stage	What happens	What drives the delay	What a vendor number usually covers
1. Capture and encode	Your voice hits a microphone, gets sampled, buffered into small frames, and compressed for transmission.	Frame size and buffering depth. Wireless earbuds add a Bluetooth link on top of this. Consumer buds rarely publish their audio latency.	Almost never included. Treated as part of "the headset", not "the translation".
2. Transport to the model	Encoded audio travels to wherever the model runs, usually a server.	Round-trip network time, plus jitter buffering to smooth out uneven packet arrival. Varies with connection, not with the product.	Usually excluded, or measured on a lab network that resembles nothing you'll use.
3. Endpointing and segmentation	The system decides whether you have finished a phrase, or are only pausing mid-sentence.	How long a silence must last before it counts as an ending. This is the single largest and least discussed cost in the whole chain.	Almost always excluded. This is the stage most products optimise for demo footage rather than conversation.
4. Speech recognition	Audio becomes words in the source language.	Whether the recogniser streams partial results or waits for a complete segment. Accent, background noise and overlapping speakers all force reprocessing.	Sometimes included, and this is the number most often quoted alone.
5. Translation	Source words become target words.	Word order between the two languages. German and Japanese park critical information at the end of a clause, so the model must either wait or guess.	Occasionally included. Rarely broken out by language pair, which is where the real variation lives.
6. Speech synthesis	Target words become audible speech.	Whether synthesis begins on the first few words or waits for the finished sentence. Published academic work on this stage reports latency reductions of 0.2 to 0.5 seconds from incremental synthesis strategies alone, which tells you how much room there is here.	Frequently excluded, because it happens after "the translation" is technically done.
7. Playback	Audio returns down the link and reaches the ear.	Network again, plus the wireless audio path. Same measurement problem as stage 1, in reverse.	Excluded.

Stage 3 is the one worth staring at. It is the stage a product can make look fast in a controlled demo, and the stage that most determines whether an actual conversation feels workable.

Why does waiting for the end of a sentence cost so much time?

A translation system that waits for a complete sentence before doing anything has a structural problem: it does not know when your sentence ended. It only knows how long you have been quiet.

So it picks a threshold. Wait 300 milliseconds of silence and you get fast responses along with constant interruptions, because normal speech is full of pauses that short. Wait 800 milliseconds and you stop cutting people off, but you've added most of a second to every single turn before any translation work has even started. Wait longer still and the system is reliable and unusable in the same breath.

That trade-off is entirely invisible in a specification sheet. It is also the reason two products running identical recognition and translation models can feel completely different in a market or a taxi.

Then language order compounds it. Translating English into Spanish, a model can start emitting target words while you're still talking, because the two languages agree on roughly where things go. Translating English into Japanese, the verb you need is at the end of the source clause, so early output is a bet. The research literature calls this anticipation, and it is a real technique: the wait-k approach introduced in the STACL paper has the model generate target words a fixed number of source words behind the speaker, accepting some guessing in exchange for a bounded, controllable lag. It is also where a chunk of translation errors come from. Faster and more literal are not the same axis.

This is why I keep saying the hardware is the least interesting part of a translation earbud. If you want the full argument, how translation earbuds actually work covers where the work really happens.

What delay does a conversation actually tolerate?

There's a useful reference point from telephony. The ITU's G.114 recommendation on one-way transmission time says a one-way delay of 400 ms should not be exceeded for general network planning, and it's explicit that highly interactive tasks degrade at considerably smaller delays than that ceiling.

That standard describes a phone call in one language. Translation cannot get near it, and pretending otherwise is where a lot of marketing goes wrong. What the number is genuinely useful for is calibration: 400 ms is roughly where an ordinary conversation starts to feel like it has a lag. Everything a translation system adds sits on top of that.

In practice the range people accept splits by use:

• Under about one second. Feels close to interpreted conversation. Very few consumer setups reach this end to end, and the ones that come close are doing streaming output rather than sentence-at-a-time output.
• One to two seconds. Workable for real back-and-forth. You learn to leave a beat after speaking. This is where the current generation of good systems actually lives, and it matches the two-second conversational figure Google's team describes.
• Two to four seconds. Fine for one-directional situations. Asking for directions, ordering, a short exchange at a counter. Frustrating for anything resembling a discussion.
• Beyond four seconds. People stop waiting and switch to gestures or a phone screen.

Notice that none of those buckets is a product claim. They're descriptions of what a conversation does at different delays, and you can map any product onto them yourself.

Why do vendor latency numbers disagree so wildly?

Because they are not measuring the same thing, and almost none of them say which thing they measured.

A concrete published example: Vasco states that its translation earbuds translate in approximately 0.5 seconds, alongside a figure of 96% translation accuracy across 51 languages. Those numbers are on their page and I'm not going to argue with their internal testing, because they haven't published a method and neither has anyone else in this category. What I can point out is arithmetic. Half a second is shorter than the endpointing threshold alone on most systems that wait for sentence boundaries. So the figure is very likely describing stage 4, or stages 4 through 6, rather than the interval you experience, which starts when you stop talking and ends when sound reaches the other person's ear.

That's not deception. It's an industry with no shared definition. Three vendors can each quote a truthful number and produce a three-way disagreement, because one timed the model, one timed the round trip, and one timed a scripted phrase in a quiet room.

Until someone publishes a method, treat every latency claim as unlabelled. Ask which two events the stopwatch started and stopped on. If a page doesn't say, the number tells you nothing comparable. The same discipline applies to language counts and accuracy percentages, which I've written about in do translation earbuds work.

What does "streaming" translation change?

Streaming is the shift from "wait, then process" to "process continuously, and correct as you go."

A streaming system starts recognising while you're still speaking, starts translating on partial input, and can start synthesising before your sentence closes. It works from a rolling window of recent audio rather than a finished utterance. Google's description of its end-to-end model puts that window at the preceding ten seconds of input, with the two-second delay acting as the model's prediction margin rather than a queue you're waiting in.

The practical difference is what happens to your pause. In a sentence-at-a-time system, the pause is dead time in which nothing is happening. In a streaming system, most of the work is already done by the time you stop, so the pause largely disappears from the perceived delay.

The cost is revision. Streaming systems change their mind. Partial output gets superseded when later words clarify the meaning, and in a speech-to-speech setting there's no way to un-say something already spoken aloud. So streaming buys you responsiveness and pays for it with occasional confident errors. Sentence-at-a-time buys you stability and pays for it in dead air. Neither is the correct answer for every conversation, which is why the better products let the trade-off shift with the situation.

How do you measure delay yourself?

You do not need equipment. You need a phone and a second person, or a phone and a video of someone speaking.

1. Record both ends at once. Put a phone in voice-memo or video mode between you and the output speaker. One recording, both signals.
2. Speak a short, hard-edged phrase. Something with a sharp consonant start, so the waveform has a clear onset. Six to eight words, one sentence.
3. Stop cleanly and stay silent. Do not trail off. The stopwatch you care about starts at the end of your last word.
4. Open the recording in any free audio editor. Find the end of your speech, then the start of the translated output. The gap between them is your real end-to-end delay for that phrase.
5. Repeat under real conditions. A cafe at lunchtime, a street, a train. Noise directly changes recognition and endpointing behaviour, so a quiet-room measurement is the best case and not the useful case.
6. Test the language pair you'll actually use. English to Spanish and English to Japanese will not produce the same number on the same hardware, for the word-order reasons above.

Run that on any two products and you have a comparison nobody's marketing department controls. It's also, honestly, the only latency comparison in this category I'd trust.

If you want to skip straight to the feeling of it, the live demo on the AIEarbuds homepage runs translation in your browser with nothing to install. Speak into it and listen for the gap. Thirty seconds of that tells you more about whether this technology fits your trip than any number on a spec sheet, including mine. That's why the demo sits at the top of the page instead of a claim.

FAQ

How fast is real-time translation?

For current consumer and cloud systems, expect roughly one to three seconds from the end of your sentence to the start of translated audio, with the better streaming systems near the bottom of that range. Google's research team describes a two-second delay as the standard setting for real-time conversation, and notes that older pipeline-style systems typically ran 4 to 5 seconds. Any figure well under a second is almost certainly measuring a single stage rather than the full path from your mouth to the listener's ear.

Why is there a delay before I hear the translation?

Mostly because the system has to decide you've finished speaking before it can commit to a translation, and the only evidence it has is silence. That decision alone can cost several hundred milliseconds. On top of it sit recognition, translation, speech synthesis and two network trips. Word order matters too: translating into a language that places the verb late forces the model either to wait for more input or to guess ahead.

Is simultaneous translation the same as real-time?

Not quite. Simultaneous means output overlaps input, which is what a human conference interpreter does and what streaming models attempt. Real-time is the looser marketing term, and it's often applied to systems that wait for you to finish a sentence before doing anything. A system can be real-time in the marketing sense and not simultaneous in the technical sense. If a product's output only ever begins after you stop talking, it is not simultaneous.

Does a faster connection reduce translation delay?

It reduces one part of it. Network transport is two segments of the budget, and a bad or congested connection makes them much worse, particularly through jitter buffering that absorbs uneven packet arrival. But upgrading from a decent connection to an excellent one changes little, because the dominant costs are endpointing and model processing, and those are unaffected by your bandwidth. If a translation feels slow on good Wi-Fi, the connection is not what you need to fix.