ACC320 Benchmarks to Fix Endpointing in Streaming ASR for Developers

Endpointing in streaming ASR works best as a layered decision, not a single trigger: a fast acoustic or semantic signal flags a candidate pause, ASR-aware cues like end-of-word (EOW) tokens confirm the linguistic boundary, and a lightweight verification pass catches edge cases before the system commits. Pure silence timers fail because they cannot distinguish a thinking pause from a finished sentence. The sections below cover the failure modes, the competing method families, the architectures that fix them, and how to measure and deploy the result.
TL;DR:
- Pure silence timers are unreliable because they cannot differentiate between thinking pauses and actual stops, especially in conversational or noisy environments.
- End-of-word tokens trained with delay penalties and lightweight VAD from encoder embeddings effectively improve endpoint accuracy without significantly increasing latency or WER.
- Duration-aware models predicting time-to-next-speech-onset outperform fixed timers by providing more precise, continuous estimates of when speech will resume, reducing premature cutoffs.
- Deployment strategies like two-pass detectors and buffer management help balance latency and accuracy, but require domain-specific tuning of parameters like window size and telemetry tracking.
- Testing endpointing approaches against multiple models and real-world audio data accelerates optimization and prevents over-reliance on lab benchmarks, ensuring robust performance across scenarios.
Table of Contents
- Why Endpointing in Streaming ASR Is Harder Than It Looks
- VAD, ASR-Conditioned, and Semantic Endpointing Compared
- Architectures That Fix the Latency-Accuracy Trade-off
- Duration-Aware Endpointing: Predicting Time-to-Next-Speech-Onset
- Metrics, Datasets, and Test Design for Endpointing
- Deployment Engineering: Chunking, Buffering, and Real-Time Budgets
- Benchmarking Endpointing Strategies Across ASR Models
- What I’d Prioritize First If I Were Building This Today
- Test Your Endpointing Strategy Across Real Models, Not Just Papers
- Sources
- FAQ
Why Endpointing in Streaming ASR Is Harder Than It Looks
The obvious approach, wait for silence and call it done, breaks down almost immediately in production. Three failure modes explain why.
Transducer-based ASR models suffer from delayed emission: the decoder often lags several hundred milliseconds behind the actual audio before it commits a token, because the model has learned to wait for more context to reduce word errors. That lag means the system’s internal state can look “finished” well after the speaker has actually stopped, or it can look mid-word when the speaker has genuinely paused. Auxiliary tokens and delay-penalty training exist specifically to counteract this drift, a fix covered in detail in the architecture section below.
The second failure mode is subtler: within-utterance pauses look identical to end-of-utterance silence to a naive timer. A speaker saying “I need to book a flight to… let me check… Denver” pauses for a full second mid-sentence. A fixed 700ms timeout will cut that utterance in half, forcing the ASR to process a fragment and the downstream NLP pipeline to guess at intent from incomplete input.
Overlap compounds both problems. In multi-talker or noisy environments, a second speaker’s onset can mask the acoustic cues a VAD relies on, or a barge-in can restart the audio buffer mid-decision. Systems tuned only on clean, single-speaker benchmarks routinely misfire once overlapping speech enters the picture, which is why multi-talker endpointing research treats it as a distinct engineering problem rather than a corner case.

VAD, ASR-Conditioned, and Semantic Endpointing Compared
Three method families dominate production speech endpoint detection, and each makes a different trade between speed, accuracy, and system complexity.
- Acoustic VAD-only: Runs on raw audio energy or a small classifier, adds almost no latency, and requires no coupling to the ASR pipeline. Its weakness is exactly the within-utterance pause problem: it cannot tell a breath from a finished thought, so it either cuts speakers off or waits too long on every hesitation.
- ASR-conditioned endpointing: Uses decoder-internal signals, such as EOW/EOS token emission or joiner state, to decide when an utterance is grammatically or semantically complete. It tracks meaning far better than raw acoustics, but it inherits every ASR error: a misrecognized word can trigger a false endpoint, and the approach only works as well as the underlying transducer’s own accuracy.
- Audio-only semantic (duration-aware): Predicts how long the current silence is likely to last based on prosody and context, without needing full ASR decoding. It sits between the other two: faster and cheaper than full ASR-conditioned decisions, more pause-aware than plain VAD.
Fixed timeout logic technically belongs to the VAD-only camp, but deserves its own mention because so many production systems still ship with it. It is trivial to implement and instant to compute, which is why it persists, but every one of its parameters (the timeout length) is a single knob fighting two opposing failure modes at once.
Choose VAD-only for tight compute budgets and short, command-style utterances. Choose ASR-conditioned when transcript accuracy is already strong and latency budget allows a decoder round-trip. Choose duration-aware semantic models for conversational speech with unpredictable pause lengths, which is most real-world dictation and voice-assistant traffic.
Architectures That Fix the Latency-Accuracy Trade-off
Four concrete techniques move the needle beyond naive timeout logic, and they compose well together.
- Add EOW/EOS tokens with delay-penalty training. Insert explicit end-of-word and end-of-sentence tokens into the training transcripts, then penalize the model during training for emitting them late. This directly counteracts delayed emission and gives the decoder a linguistic signal it did not have before, improving endpoint precision without degrading WER when the penalty weight is tuned carefully.
- Power a lightweight VAD from encoder embeddings. Instead of running a separate acoustic model, tap the ASR encoder’s own hidden states and train a small classifier on top. This reuses compute the system already spends on transcription and keeps the VAD tightly synchronized with what the ASR is actually hearing, a design detailed in the multi-talker endpointing work from Microsoft Research.
- Deploy a two-pass EP Arbitrator. Run a cheap, fast first-pass detector on every frame, then only invoke a heavier verification model when the first pass flags a candidate endpoint. This architecture improves the early-cutoff/latency trade-off across voice-assistant and conversational datasets, because the expensive check only runs when there is something worth checking.
- Use decoder-state features for framewise end-of-utterance probability. An LLM-based predictor trained on 1-best hypotheses can output an end-of-utterance probability per frame without running live decoding at test time, cutting runtime cost while preserving low endpoint error.
Pro Tip: Set your verification window to roughly the same duration as your average expected within-utterance pause for the domain. If your users are dictating addresses or reading numbers aloud, that window should be longer than for quick voice-assistant commands, or the arbitrator will still cut people off mid-thought.
Duration-Aware Endpointing: Predicting Time-to-Next-Speech-Onset
Rather than classifying “speaker done or not done” as a binary, duration-aware models predict a continuous value: how many milliseconds until the next speech onset. That regression target carries far more information than a yes/no label, because it captures how confident the model is about a pause’s length, not just whether one exists.
- Training labels come directly from raw speech timestamps in the audio, with no manual semantic annotation needed, which lets these models scale to large unlabeled corpora.
- Graded supervision, where the model learns the actual gap length rather than a threshold-based label, helps specifically with mid-utterance pauses, the hardest case for fixed timers.
Duration-aware models predicting time-to-next-speech-onset produced a 25.9% absolute improvement in endpoint accuracy within 320 milliseconds (ACC320) over the strongest baseline in published experiments.
Two implementation details make this approach streaming-compatible rather than a research curiosity. First, training uses random audio cut-offs, deliberately truncating input clips mid-utterance, so the model learns to make duration predictions from partial context instead of only from complete utterances. Second, the duration head is trained jointly with a standard binary endpoint-detection (EPD) objective, so the model still outputs a usable go/no-go signal at inference time even though it learned from a richer regression target.
At inference, convert the predicted duration into an endpoint score by thresholding: if predicted time-to-onset exceeds your chosen cutoff (say, 300ms), fire the endpoint. Lower thresholds favor responsiveness; higher thresholds favor avoiding premature cutoffs. On constrained hardware, smaller backbones trained with this duration-aware objective and random cut-off training still deliver strong ACC320 gains, making the approach viable for embedded and edge deployments, not just cloud-scale systems.
Metrics, Datasets, and Test Design for Endpointing
ACC320, which measures endpoint accuracy within a 320-millisecond tolerance window, has become the standard headline metric for endpointing research, but it should never be reported alone. Endpoint Interval (EI) captures the gap between predicted and true endpoint time, while precision, recall, and F1 on endpoint events reveal whether a system is biased toward premature cutoffs or laggy confirmations. Critically, endpoint metrics should always be reported alongside WER: a system that improves endpoint precision by aggressively cutting utterances short will often show a worse downstream WER, because truncated audio gives the ASR less context to work with.

Standard benchmarking draws on Librispeech for clean read speech, Switchboard for conversational telephone audio with natural disfluencies, and SLURP for spoken-language-understanding style commands. Multi-talker and overlap testing calls for CHiME or LibriMix, since single-speaker corpora simply do not exercise the failure modes overlapping speech creates.
Beyond static benchmarks, a reproducible test harness should inject artificial pauses of varying length into held-out audio, layer in synthetic overlap and multiple noise profiles, and finally validate with a production A/B test measuring real user barge-in and repeat-request rates, since lab metrics do not always predict how users actually react to a slightly-too-eager endpointer.
Deployment Engineering: Chunking, Buffering, and Real-Time Budgets
Getting the model right solves half the problem. The other half is the plumbing that decides how audio reaches the model and how results reach the user.
- Chunk size and look-ahead directly trade against latency. Larger chunks with more look-ahead context improve endpoint F1 because the model sees more of the pause before deciding, but every added millisecond of look-ahead is a millisecond the user waits. Most production systems settle on 20 to 100ms chunks depending on how latency-sensitive the use case is.
- Buffering strategy determines whether your audio callback thread ever glitches. Low-latency audio work runs on a dedicated real-time thread that must never block, a discipline covered well in guides to low-latency audio thread programming; dropping a single audio callback frame can desynchronize your endpoint timing from the actual audio stream.
- Interim and final hypotheses interact with your endpoint parameters in non-obvious ways. If your endpointer fires on the interim hypothesis before the final pass corrects a misrecognized word, you can commit to the wrong transcript. A conservative default is to require the interim hypothesis to remain stable across two consecutive chunks before treating an endpoint candidate as real.
- Instrument telemetry per utterance, not just in aggregate. Track start time, candidate endpoint time, final endpoint time, interim confidence scores, and the joiner’s last emitted token. This level of detail is what lets you distinguish premature endpoints from delayed ones after the fact instead of guessing from aggregate WER alone.
Real-time factor, the ratio of processing time to audio duration, should stay comfortably under 1.0 across your full pipeline, endpointer included, or your system will fall behind live audio during sustained speech.
Benchmarking Endpointing Strategies Across ASR Models
Endpointing decisions cannot be tuned in isolation from the ASR backbone generating the transcript, because delayed emission, WER, and endpoint accuracy all interact. That means any serious tuning effort needs a way to run the same endpoint logic against multiple model backbones and compare results on equal footing.
The telemetry worth capturing per stream includes the endpoint timestamp itself, the model’s confidence at that timestamp, how far the interim hypothesis diverged from the eventual final transcript, and WER computed specifically under your endpoint rule rather than on the full clean reference.
- Accuracy: ACC320 and WER under your endpoint boundary, not just overall WER.
- Latency: time from true speech end to committed endpoint decision.
- Cost: per-second billing across models, since cheaper backbones sometimes trade a small ACC320 loss for meaningfully lower cost per stream.
- Real-time factor: whether the model and endpointer combined stay under your live-audio budget.
| Benchmark axis | What to log | Why it matters |
|---|---|---|
| Accuracy | ACC320, endpoint F1, WER-at-endpoint | Detects premature cutoffs masked by good raw WER |
| Latency | True-end to endpoint-decision time | Direct driver of perceived responsiveness |
| Cost | Per-second billing per backbone | Determines which model is viable at scale |
| Real-time factor | Total pipeline time / audio duration | Confirms the system stays ahead of live audio |
A concrete experiment plan: pick three or four candidate models from a model catalog, run identical audio through each with the same endpoint logic, and log the table above per stream to see which backbone actually earns its cost at your target latency.
What I’d Prioritize First If I Were Building This Today
Most teams overbuild endpointing before they have measured their baseline. Start with plain VAD, measure ACC320 and WER-at-endpoint honestly, and only then decide whether the gap justifies EOW/EOS training or a duration-aware model. In my reading of the research, the biggest wins come from combining cheap signals rather than replacing one expensive model with another.
The sequence that makes sense: baseline VAD, then add EOW/EOS tokens with a delay penalty, then layer in a duration-aware model if mid-utterance pauses are still causing complaints, then finally add a two-pass arbitrator only if false endpoints remain costly enough to justify the extra compute. Skipping straight to the arbitrator without first fixing the underlying signal quality just adds latency to a badly-timed decision.
Before rollout, confirm you have per-utterance telemetry, a documented conservative default timeout, and a rollback plan if false-cutoff complaints spike after a change. Heuristics beat model changes whenever the failure is a tuning problem, not a modeling one.
— Benjamin
Test Your Endpointing Strategy Across Real Models, Not Just Papers
Every technique in this article, from EOW-token tuning to duration-aware thresholds, only proves out once you run it against real audio on a real model backbone, and that is where most teams stall: swapping ASR providers to test a hypothesis usually means new SDKs, new billing, and new integration work. You can find API access to many transcription models behind one interface, with realtime streaming, word-level timestamps, confidence scores, and speaker diarization exposed per stream.

Because billing is per-second with no subscription, you can run the exact benchmark table from the section above, accuracy, latency, cost, real-time factor, across several backbones in an afternoon without committing long-term. Check the realtime model rankings to see current latency and accuracy standings before you pick candidates, then browse the model catalog to shortlist backbones that fit your cost ceiling. Start a comparison today at OpenTranscription and get structured, timestamped transcripts back from your first test stream.
Sources
For teams building or reviewing an endpointing system, these sources cover the methods discussed above in full technical detail:
- Next-Turn: Duration-Aware Streaming Endpoint Detection via Time-to-Next-Speech-Onset
- Two-Pass Endpoint Detection for Speech Recognition
- Endpoint Detection for Streaming End-to-End Multi-talker ASR
FAQ
What Is Endpointing in Streaming ASR?
Endpointing is the process of deciding, in real time, when a speaker has finished an utterance so the ASR system can finalize a transcript instead of waiting on open-ended audio. It directly governs the latency users perceive in any voice interface.
How Does Endpointing Differ From Voice Activity Detection?
VAD only detects whether audio contains speech versus silence or noise, while endpointing decides specifically whether a speaker has finished their turn. Endpointing typically uses VAD as one input alongside ASR-aware signals like EOW tokens.
What Metric Should I Use to Compare Endpointing Systems?
ACC320, endpoint accuracy within a 320-millisecond tolerance, is the most common headline metric, but it should always be reported with WER-at-endpoint and latency, since optimizing endpoint precision alone can degrade transcript quality.
Can I Test Different ASR Models’ Endpointing Behavior Without Switching Providers?
Yes. Platforms like OpenTranscription let you run the same audio through multiple models via one API and compare endpoint latency, accuracy, and cost side by side without separate integrations.
Does a Two-Pass Arbitrator Always Improve Endpointing?
Not always. It improves the trade-off between early cutoffs and latency mainly when the added verification compute is affordable within your latency budget; for very low-latency command interfaces, a well-tuned single-pass system can outperform it.
