Endpointing latency short reply

open

2 independent reportsacross 2 sourceson 2 stackslast reported 2026-04-27

What this is

After switching to neural voice-activity detection, the system takes an unusually long time to respond when the caller gives a short one-word reply.

Status open: reported and still open where it was reported.

Evidence

Sanchit_Singh2026-04-27livekitcommunity.livekit.iocommunity.…y-issue/958

i’m seeing high eou delay and high turn detection inference i’m using multilingual turn detection model which claims 50-160 ms inference time but in my case it’s around 700-1 sec...

First seen 2026-04-27 · our copy fetched 2026-07-25T18:25:37Z · SHA-256 of that copy begins ba1655a942c9474b… · profile

rojithaDev2025-03-30ultravoxGitHub issuesgithub.com/…/290

Slow responses with short one word replies

First seen 2025-03-30 · our copy fetched 2026-07-25T17:50:37Z · SHA-256 of that copy begins c7399707deeb5c2f… · profile

Quotes run to 30 words around the reported failure and link to the post.Add your call to this entry Take a quote down within 24 hours.

What is measurable

Signal	`hotato autopsy ./call.wav` maps to this mode as detector kind `long_response_gap`. The silence between the caller finishing and the agent responding. Printed as DEAD AIR at 5 seconds or more, and as LATENCY SPIKE between 2 and 5 seconds.
Establishes	The seconds of silence between the caller finishing and the agent answering, timestamped in the call. What else it establishes, and what your own trace settles Dead air is visible in a single mixed channel, so this one is measurable on a mono recording as well as a split one. What your trace settles Your latency spans for that turn name where the seconds went: transcription, the model, or speech synthesis.
Tier	Tier 3 · single mixed channel: one mixed channel still measures what silence shows, and each finding carries its measured confidence. hotato is MIT and runs locally, getting started.

Status history

The record has carried one status since it opened: open, reported and still open where it was reported. A move lands here with the link, the quote and the date that show it.

Mode	Status	Shares
VAD endpoint misdetection	open	reported on livekit; reported on github; reported on livekit_forum
Endpoint misdetection	acknowledged	reported on livekit; reported on github; reported on livekit_forum
VAD fires but STT yields no transcript	fixed	reported on livekit; reported on github; reported on livekit_forum

Discussion

Reader discussion of this mode: what fixed it and what did not. The reports above are attributed and linked; a comment is a comment.

Open this discussion on GitHub

The record

Ids, digests, every link this entry stands on, and how to take a quote down

Atlas id	`VFA-2025-0001`
Mode id	`pat_d636db67e9409ac2a305794a`
Content digest	`sha256:d636db67e9409ac2a305794a46dc902bbec8407be69c7f247f693f878da6b4c5`
First reported	`2025-03-30`
Last reported	`2026-04-27`
First seen by the atlas	`2025-03-30T23:59:45Z`
Last re-checked	`2026-04-27T16:18:49.899Z`
Reported on	livekitultravox
Sources	GitHub issues, community.livekit.io
Scope	2 independent public reports across 2 sources. This entry states where the mode has been reported; where else it can occur is what the next report settles.
References	reporthttps://community.livekit.io/t/high-turn-detection-latency-issue/958 · Sanchit_Singh · community.livekit.io · 2026-04-27 reporthttps://github.com/fixie-ai/ultravox/issues/290 · rojithaDev · GitHub issues · 2025-03-30
Machine surfaces	feed.json feed.atom feed.schema.json atlas.llms.txt
Removal	If you wrote something quoted on this page and want it gone, one email to atlas-remove@hotato.dev does it. The removal path takes the quote, the handle and the link off this page, out of the feeds and out of the llms.txt within 24 hours, and tombstones the id so the entry cannot quietly return at a new address.