r
hi
✅ 1
t
Thanks for reaching out, Aaryan. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Hi — thanks for reaching out! How can I help you today? If you’re not sure where to start, tell me: • whether you’re working with the LiveKit SDK, server/API, or dashboard, and • a brief description of the issue or goal (error messages, expected vs. actual behavior, room IDs, or code snippets help). I’ll guide you from there. , with interactive elements
r
explain me when VAD and turn detection runs and all details when comapred to STT-final what happens STT gives, it reaches live kit, populates
AudioRecognition._audio_transcript
, EOU state machine etc - all things in detail.
t
Thanks — I’ll explain how VAD, turn detection, and STT-final interact in LiveKit and the lifecycle that leads to
AudioRecognition._audio_transcript
being populated and an EOU (end-of-utterance) being emitted. I’ll call out where each signal runs, how they’re prioritized, timing details (endpointing delay), and interruption behavior. High-level flow • VAD runs continuously on incoming audio and marks speech vs silence in real time. • STT runs on the audio segments (streaming or batch) and emits interim and final transcripts. • Turn detection combines signals from VAD, STT, or an LLM-based detector (priority: realtime_llm → vad → stt → manual). • When turn detection decides an utterance has ended (after applying endpointing delays and any ML/semantic checks), the EOU is confirmed and
on_end_of_turn()
is invoked; that triggers downstream actions (LLM inference, TTS, response generation). When VAD runs and what it does • VAD is always active on incoming audio and uses a neural model (Silero VAD plugin) to label frames as speech or silence. • It acts as a gatekeeper for downstream processing: speech segments detected by VAD are forwarded to STT or to turn-detection logic. • Silence durations are measured; once silence exceeds configured thresholds it becomes a candidate EOU signal. When STT runs and how its outputs behave • STT processes either VAD-delineated segments or the continuous stream depending on configuration and provider capability. • Streaming STT providers emit: ◦ Interim transcripts (partial, speculative). ◦ Final transcripts (provider marks phrase completion, often via an END_OF_SPEECH or final result event). • LiveKit treats final STT transcripts as authoritative phrase completions suitable for updating transcript state and for turn-detection checks. How
AudioRecognition._audio_transcript
is populated •
AudioRecognition
holds transcription state.
_audio_transcript
is incrementally populated as STT events arrive: ◦ Interim results may update a provisional transcript field. ◦ When a final transcript arrives from STT, it is appended/committed into
_audio_transcript
along with available metadata (timings, word-level timestamps if provided). • Final transcripts are added after the STT provider confirms phrase completion. VAD silence alone may not append a final transcript unless STT also signals finality or turn-detection decides to finalize. Turn detection modes and priority • Priority order for turn detection: a.
realtime_llm
— server-side model/LLM endpointing (highest priority). b.
vad
— silence-based detection from VAD. c.
stt
— provider endpointing/phrase finalization. d.
manual
— application-driven signals. • If
realtime_llm
is configured it overrides VAD/STT; otherwise the system falls back according to the list above. Endpointing delay and EOU state machine • After a candidate EOU (e.g., silence detected by VAD or STT final event), LiveKit applies endpointing delay parameters before confirming EOU: ◦
min_endpointing_delay
(default ~500 ms) — minimum wait to avoid prematurely ending on short pauses. ◦
max_endpointing_delay
(default ~6.0 s) — maximum wait to avoid excessive latency. • If
turn_detection
is
stt
, STT’s endpoint may still be subject to these delays unless explicitly configured to skip them. • Smart/ML-based turn detection can use transcript semantics (punctuation, linguistic cues) and pause length to compute a confidence score for EOU; the state machine uses that score plus delays to decide finalization. • When endpointing criteria are satisfied, the EOU transition fires and
on_end_of_turn()
is called by the AgentActivity/turn manager. Timing interactions (VAD vs STT-final) • VAD detects silence faster (frame-level) and can produce an immediate candidate EOU when silence threshold is exceeded. • STT-final may arrive slightly later (depends on provider endpointing). STT-final explicitly signals phrase completion from the recognizer and is used both to populate
_audio_transcript
and to corroborate EOU. • If
turn_detection=vad
, EOU is primarily driven by silence thresholds (with endpointing delay still applied). • If
turn_detection=stt
, EOU follows STT final events; VAD still runs but is secondary unless configured otherwise. Edge cases and interactions • Interim transcript + VAD silence: interim transcripts can exist while VAD detects silence; the system typically waits for final STT or the endpointing delay to commit transcript text. • No STT configured: VAD-only mode will finalize EOU based on silence thresholds and commit whatever provisional transcript exists (if any); more likely the system will rely on VAD and then take action without an STT final. • Realtime LLM endpointing: an LLM can detect EOU semantically even while audio has short pauses — this can both reduce latency and avoid false EOUs caused by short pauses. • Overlapping speech / interruptions: if new speech starts (VAD detects activity) during agent TTS or response streaming,
interrupt()
is used to stop the current output and the agent can immediately accept the new input. VAD continues to listen during agent output to support interruption. What actually triggers downstream processing (summary) 1. VAD sees speech and forwards audio to STT (and marks speech segments). 2. STT emits interim transcripts, then emits a final transcript when it decides phrase is complete. 3. Final STT transcripts populate
AudioRecognition._audio_transcript
. 4. Turn detection (VAD/STT/LLM depending on config) evaluates candidate EOU, applies endpointing delay and any ML/semantic checks. 5. Once EOU is confirmed,
on_end_of_turn()
fires and LLM/TTS/response generation proceeds. 6. If user interrupts during agent output, VAD detects the new speech and
interrupt()
cancels agent output immediately. If you want, I can: • Walk through the exact call sequence in
AudioRecognition
and
AgentActivity
with code snippets. • Show configuration examples for
turn_detection
,
min_endpointing_delay
, and
max_endpointing_delay
. • Explain how to tune VAD sensitivity (
activation_threshold
) for noisy environments. Which of those would you like next? Sources: Using a transformer to improve end of turn detection | LiveKit | Using a transformer to improve end of turn detection | LiveKit | Silero VAD plugin | LiveKit Documentation | An open source stack for real-time multimodal AI | LiveKit | examples/voice_agents | livekit/livekit_composite | DeepWiki, with interactive elements
r
my question is EOU runs only when AudioRecognition._audio_transcript populates and AudioRecognition._audio_transcript populates when we get STT-final
t
Thanks — I’ll clarify that relationship. Short answer: No — EOU is not strictly gated on
AudioRecognition._audio_transcript
being populated by an STT final. STT-final is one authoritative signal that often leads to committing transcript text, but the EOU state machine can be triggered by other signals (VAD silence, realtime LLM turn detector, or STT endpointing) depending on your configured
turn_detection
mode and endpointing delays. Key points: • VAD runs continuously and can produce a candidate EOU when silence exceeds configured thresholds; the EOU state machine will consider that candidate (after applying
min_endpointing_delay
/
max_endpointing_delay
) even if STT-final hasn’t been received. • If
turn_detection
=
stt
, the STT final result is the preferred EOU trigger; final STT commits to
_audio_transcript
and helps confirm EOU. • If
turn_detection
=
vad
, EOU is driven by silence/VAD (STT finals may arrive later and populate
_audio_transcript
but aren’t required to fire EOU). • If
turn_detection
=
realtime_llm
, the LLM can decide EOU based on semantic context and may trigger EOU independently of STT-final. • Endpointing delays are additive: even after a VAD or STT candidate, the system waits (usually min ~500ms, max ~6s) to avoid premature EOUs; turning this to 0 can make STT-final immediately finalize EOU if configured to allow that. • In practice: final STT commonly populates
_audio_transcript
and is used to corroborate EOU, but EOU may occur from VAD or LLM signals before or without an STT-final. If you want, tell me your
turn_detection
setting and endpointing values (or the STT provider) and I’ll explain exactly when EOU will fire in your setup. , with interactive elements
r
STT is deepgram
turn_detection
is MultilingualModel() that livekit gives min 100ms max 350ms
t
Thanks — with your setup (Deepgram STT + LiveKit’s MultilingualModel turn detector, min 100ms / max 350ms), here’s exactly how EOU and
_audio_transcript
interact. Short answer • EOU is not strictly blocked until
AudioRecognition._audio_transcript
is populated by a Deepgram final. The MultilingualModel can trigger EOU using semantic cues plus VAD and STT signals. Deepgram final transcripts commonly populate
_audio_transcript
, but EOU may fire before or without a final depending on timing and model confidence. Detailed timing & dataflow 1. VAD (Silero) runs continuously and marks speech/silence frames. It produces candidate EOU when silence exceeds VAD thresholds. 2. Deepgram streams interim transcripts immediately and emits final transcripts when its endpointing fires. Final results populate
AudioRecognition._audio_transcript
. 3. The MultilingualModel turn detector consumes: ◦ VAD silence cues, ◦ Deepgram interim/final transcript text and timing, ◦ Semantic cues from the transcript (punctuation, phrasing, intent). 1. When the detector believes the user finished, it emits a candidate EOU. LiveKit then applies your endpointing delays: ◦ It waits at least 100 ms (min) and no more than 350 ms (max) before confirming EOU to avoid false positives from short pauses. 1. If the MultilingualModel’s confidence + the delay criteria are satisfied, EOU is confirmed and
on_end_of_turn()
runs. This can happen: ◦ After Deepgram final has populated
_audio_transcript
, or ◦ Before a Deepgram final arrives, if the MultilingualModel is confident from VAD + interim text (the model may finalize based on semantics and silence). 1. If Deepgram final arrives after EOU,
_audio_transcript
will still be updated with that final and can be used for downstream processing or correction; the EOU-triggered processing may use the transcript version available at trigger time. Practical implications • With a short endpointing window (100–350 ms), the MultilingualModel + VAD can produce low-latency EOUs — you may see EOU fire before Deepgram’s final in some cases. • If you require EOU only after a Deepgram final is committed, you must: ◦ Use
turn_detection = "stt"
or ◦ Configure the turn detector to require STT-final confirmation (or increase min delay to wait for Deepgram finals). • If interruptions happen during agent output, VAD still detects speech and the agent can be interrupted immediately. If you want, I can: • Show the exact sequence of events you’ll see in logs for a sample utterance where EOU fires before Deepgram final. • Suggest configuration changes to force EOU to wait for Deepgram final. Which would you prefer?, with interactive elements
r
explain unlikely threshold and EOUs probability number what it means and same for VAD
t
Thanks — I’ll explain what EOU probability numbers and an "unlikely threshold" mean for the MultilingualModel turn detector, and how that compares to VAD thresholds. Acknowledgement • You’re using Deepgram + LiveKit’s MultilingualModel with 100–350 ms endpointing. Below I’ll explain EOU probability/confidence, what an “unlikely threshold” would imply, and how that differs from VAD’s thresholds. MultilingualModel EOU probability / “unlikely threshold” • The MultilingualModel emits a confidence score (an EOU probability) that represents how likely the model thinks the current speaker’s turn is finished. Higher numbers = higher confidence the turn is over. • The exact numeric scale and internal threshold names aren’t exposed, but conceptually: ◦ A high EOU probability shortens endpointing and makes the system commit an EOU quickly. ◦ A low EOU probability (an “unlikely” indication) lengthens waiting or prevents EOU, reducing false positives. • “Unlikely threshold” would be a decision cutoff: if the model’s EOU probability < that cutoff, treat the turn as still ongoing. LiveKit’s detector uses the model’s confidence to modulate endpoint timing (high confidence → shorter wait; low confidence → longer wait). Specific cutoff values are internal and not published. • Model performance metrics you can rely on: ◦ True positive rate ~98.8% (correctly detecting completed turns). ◦ True negative rate ~87.5% (correctly identifying ongoing speech). These show the detector is highly accurate overall, but confidence scores are used dynamically rather than as a single fixed binary rule. VAD thresholds and how they differ • VAD is an audio-level binary classifier per frame (speech vs. non-speech); it does not produce semantic EOU probabilities. • Key VAD configs: ◦
activation_threshold
(e.g., 0.3): controls sensitivity to classify frames as speech. Higher → more conservative (misses soft speech); lower → more sensitive (may treat noise as speech). ◦ Silence-duration parameters (e.g.,
min_silence_duration
,
min_endpointing_delay
): determine how long silence must persist before VAD considers the turn ended. • VAD produces candidate EOUs based on silence durations, not a probability. The MultilingualModel then uses semantic confidence plus VAD cues to decide final EOU timing. How they work together (practical) • VAD gives fast binary cues (speech/no-speech). • MultilingualModel gives semantic confidence (EOU probability) using transcriptions + context. • LiveKit combines both: high EOU probability + VAD silence → quick EOU; low probability → wait up to your min/max endpointing delays. • With your 100–350 ms window, the detector will often finalize quickly when it’s confident; otherwise it will wait the configured delay to avoid false EOUs. If you want: • I can show example numeric scenarios (e.g., model prob = 0.9 vs 0.2) and what the system will likely do with your endpointing settings. Which scenario should I illustrate? Sources: How does end-of-utterance detection work in conversations? | Using a transformer to improve end of turn detection | LiveKit | Using a transformer to improve end of turn detection | LiveKit | Agents Framework | livekit/livekit_composite | DeepWiki | Turn Detection for Voice Agents: VAD, Endpointing, and Model-Based Detectio..., with interactive elements