Live translation
How to tune VAD silence timeout for live translation
Tune VAD silence timeout from observable failures such as split model numbers, merged sentences, and late finals, using one repeatable recording.
Lab Editorial3 min read
VAD silence timeout answers one operational question: how long must the host stop before the current utterance is final and ready for translation?
A shorter value can release text sooner and split a sentence too aggressively. A longer value can preserve natural pauses and keep captions waiting. The right answer belongs to your host and script, not to a copied millisecond value.
Separate three symptoms
A phrase splits internally. “This is model A / 17 Pro” becomes two results and the second loses product context. Raise timeout or first remove the pause from delivery.
Separate sentences merge. Product explanation and the next offer become one caption block, delaying speech playback. Lower timeout or make sentence-end pauses clearer.
The final arrives late. The host has stopped but the partial result remains open. Confirm that endpoint waiting, not the network or translation stage, owns the delay before lowering timeout.
Do not call all three “latency.” Our latency budget guide separates segmentation, recognition, translation, synthesis, and playback. Only a segmentation problem belongs here.
Official guidance gives direction, not your value
Azure Speech’s official silence handling documentation states that higher segmentation silence values generally produce longer results and allow longer pauses, but return later. Lower values produce shorter, more frequent results and can divide a single phrase. It documents 100–5000 ms, with 500 ms as a typical default, and recommends changing the setting only for a real silence-handling problem.
The actual ObsTrans control is Basic settings → Live translate pause, with a 200–6000 ms range, 100 ms step, and 500 ms default. It applies only to the real-time simultaneous route labelled Advanced online recognition. Do not copy Azure’s 100–5000 ms range into ObsTrans; the two numbers belong to different products, and the Azure citation supports only the endpointing trade-off and adjustment direction.
Run an A/B test on one recording
Use real broadcast audio containing:
- continuous product explanation;
- two prices;
- one alphanumeric model;
- a natural thinking pause;
- a transition from product detail to offer.
Run the current setting and mark boundaries plus time from stopped speech to final caption. Move one step and replay the same clip. Record:
| Observation | Acceptance question |
|---|---|
| Prices and models | Do they remain in one meaningful unit? |
| Separate sentences | Do they avoid merging into a paragraph? |
| Final wait | Can the team tolerate it at production pace? |
| TTS | Does playback avoid a stream of tiny fragments? |
Do not also change microphone processing, engine, or speaking rate. Multiple variables destroy attribution.
Change delivery before distorting the whole session
For numbers and identifiers, wording is often the narrower fix. Microsoft’s documentation uses a grouped serial number such as ABC-123-4567 as the example for trying a longer 2000 ms timeout. In live selling, the host can first say “the full model is A17 Pro” without pauses between components.
Raising the global timeout for one difficult item delays every ordinary sentence. Frequent problem phrases belong in the localized script; timeout should fit the overall delivery pattern.
What ObsTrans can and cannot do
ObsTrans exposes this control without requiring code changes, and its workbench shows partial versus final state so an operator can see whether the system is still waiting for an endpoint. Local recognition and the ordinary online recognition route do not use this control, so it cannot explain their segmentation.
It cannot infer one permanent value from a single rehearsal. A new host, microphone distance, or speaking style changes the evidence. Store the accepted setting with the test recording and score sheet, not as an unexplained number in a chat message.
Steps
- 1
Record speech that reproduces the problem
Include continuous explanation, prices, model numbers, and natural pauses. Do not replace real delivery with a deliberately slow read; keep one recording for every comparison.
- 2
Classify the observed failure
Mark it as splitting inside a phrase, merging separate sentences, or waiting too long for a final result. Each category has a different adjustment direction.
- 3
Change only the segmentation interval
Under ObsTrans Basic settings, move Live translate pause in 100 ms steps. Raise it for unwanted splits and lower it for merged or late results without changing the microphone, engine, or speaking rate.
- 4
Score completeness and wait together
For each setting, note whether prices and model numbers remain intact, whether sentences merge, and the time from stopped speech to final caption. Latency alone drives the value too low.
- 5
Rehearse at production pace
Repeat with the real host, music, and an operator interjection. A clean test clip does not prove that production turn-taking will preserve the same endpoints.
Frequently asked questions
- Does a shorter timeout always mean better latency?
- It can trigger finals earlier, but an overly short value splits context into fragments and makes TTS play many short pieces. Judge completeness and delay together.
- What should I do when prices or model numbers split?
- First reduce unnecessary pauses inside the item. If the split remains, raise timeout gradually. Microsoft uses grouped serial-number speech as an example that may need a longer value.
- Why did a setting stop working with a different host?
- Endpointing reacts directly to speech rate, within-sentence pauses, and turn-taking. It is a configuration for a delivery pattern, not a permanent constant for a language pair.
KeywordsVAD silence timeoutlive translation segmentationspeech endpointingtranslation latencyObsTrans settings
