Most of the delay in live translation is waiting: for the stream, for the next word, for the sentence. The one part you control is the latency mode: less delay, or fewer revisions.
A listener reading a live translation sees each line a few seconds after the speaker said it. That gap is not one delay but several, added up along a chain, and most of them are a form of waiting. Knowing which wait is which makes the latency mode an easy choice, and tells a developer building a reader what to render, and when.
A useful yardstick before the numbers: a human simultaneous interpreter typically speaks two to four seconds behind the speaker. Interpreters call that gap the ear-voice span, and they cope with verb-final languages not by waiting for the verb but by anticipating it, or by chunking the sentence into pieces that can stand alone. A second or two of delay is not a defect of software; it is roughly what a very good human does.
Every live transcription on VocalStack passes through the same stages, in the same order, and each one waits for the one before it.
The original-language text reaches a reader almost as it is spoken. The translation follows a second or two later, and the spoken sentence comes after its translation, which is why a voice clip always arrives last. The chain's first visible effect, though, comes long before any voice: the text itself moves.
The first thing people notice in a live transcript is that the newest words move. A phrase appears, changes, and settles. That is the draft stage at work, and it exists for a reason that applies to every speech recogniser.
A recogniser settles a word by looking at what comes after it. "I scream" and "ice cream" sound the same until the next word arrives; a trailing "s" may belong to this word or the next. Until there is audio to the right of a word, its spelling is a guess, so the newest words in any live transcript are always the least certain ones. A draft is simply that guess shown early rather than hidden.
Each draft fully replaces the live tail: the words heard since the last commit, which are still changing. A commit is final. It never changes, it carries word-level timings, and commits are numbered without gaps so a reader can tell if it missed one.
For a developer this is the one rule the realtime API insists on: render every committed segment, then the latest draft after them, and clear the draft when a commit arrives. Appending drafts instead of replacing them produces duplicated, flickering text; the commit simply consumes the tail. The WebSocket tutorial builds a reader around exactly this.
For a host, moving text is the price of low delay. Showing words before the phrase is finished is what makes the transcript feel live. The translation, though, cannot afford that trick, because a word can be guessed from half a phrase, but a translation cannot.
Word order is why translation cannot keep pace with the draft. A German verb may sit at the end of its clause, and Japanese puts the verb last. Any translator needs the whole clause before rendering it faithfully. Translating word by word hands a listener fragments that have to be unread when the clause closes. German has made interpreters wait for the verb since long before software tried it.
VocalStack therefore translates sentences, not segments. Sentences are on by default, and with them on, the server assembles commits into a sentence and translates the whole of it. While the sentence is open its translation is provisional; once it closes, the translation is final. A reader holds one entry per sentence and replaces it as updates arrive.
Speech waits longer still. Only a closed sentence is spoken, because a sentence that is still changing would be re-synthesised on every revision. A long sentence is voiced in pieces, so the first can play while the rest are made.
With sentences off, each commit gets its own translation frame instead. That path waits for nothing, but whole sentences read far better.
All of these waits are measured from the moment audio reaches VocalStack. For many broadcasts, the audio was already late when it got there.
When the source is a stream rather than a microphone, the audio is already behind before anything is transcribed. It lags the live edge, the newest moment the stream has published.
A plain HTTP audio stream, the kind most internet radio stations publish, typically runs a second or three behind. The server keeps a burst buffer: a few seconds of recent audio, sent all at once so a new listener's player can start without stalling. Every listener, VocalStack included, joins that far back. HLS is worse: its playlists start a client three segments behind the live edge, which in practice means several seconds to half a minute depending on segment length. Standard DASH usually lands in the same range as HLS; only its low-latency variant gets well under it. A station's "live" stream can be live in the way a letter is current.
These figures are approximate, and they belong to the stream, not the transcription: no setting on VocalStack's side can claw them back. If those seconds matter for an event, feed the stage audio in from a microphone or an encoder rather than a public stream. Stream delay is fixed before VocalStack hears a word; the latency mode is what you can actually move.
The latency mode does one thing: it sets the balance between delay and accuracy. The setting sits under Advanced when a live transcription is created, and on the Speed tab while it runs. There the chip reads AUTO, SPEED or ACCURACY (Fast appears as SPEED). Over the API, session.update changes it mid-stream.
The trade is the one the names suggest. Fast gets text out sooner but revises more of it; Accuracy takes a little longer and revises less. A seated audience reading translated subtitles rarely notices an extra second, but does notice words that keep changing. Accuracy is therefore often the kinder setting, as long as the delay chart stays flat. Auto shows its hand: a line it sped up to close a gap carries a FAST MODE badge in the host's transcript, with a note that accuracy may be lower there.
Whatever the mode, the transcription has to be ready before the first word, and getting it ready is the one delay the chain pays only once.
On some plans a live transcription takes a few seconds to start. How long depends on the plan: the Start-up speed row on the pricing page runs from a cold start of up to 15 seconds on pay as you go to always warm on Enterprise.
Over the API, the wait shows up as session.loading frames while the session starts, then a session.ready; the client sends audio only after that. A listener who opens the link in the meantime sees "Live. The first line appears in a moment." Once the transcription is running, this delay is behind you, and the only question left is how much of the remaining delay you are carrying.
While a live transcription runs, the host's Speed tab shows what all of this adds up to: the current gap between the speaker and the text, with the mode chip beside it, and a chart of that gap across the recording with its average and peak. In the transcript itself, a line that reached listeners late carries a badge giving the number of seconds between when it was spoken and when it arrived.
A chart that stays low and flat means the mode suits the audio. A climbing chart means the pipeline is falling behind. On Accuracy, that may be the moment to move to Auto, which trades some accuracy for speed until the gap closes.
Developers get a single number instead. When a realtime session ends, session.done carries stats.realtimeFactor, the audio transcribed divided by the time spent transcribing it. One convention warning: in speech-recognition literature, real-time factor usually means the inverse, processing time over audio time, where lower is better. VocalStack reports it the other way round, so here higher is better: a live session sits near 1, and below 1 means audio arrived faster than the pipeline could transcribe it.
None of these seconds are mysterious. Some belong to the stream, some to a word waiting for the word after it, some to the sentence a translation needs, and the rest to the latency mode you chose. The API reference has the frame-by-frame detail, and the demo on the home page shows the chain running.
