stocky-oil-29870
02/17/2026, 11:42 AMtall-airline-16756
02/17/2026, 11:42 AMtall-airline-16756
02/17/2026, 11:43 AMenable_diarization can be used with LiveKit Agents so an LLM can respond using speaker-aware context, and you’d like an example.
Short answer
• The Deepgram STT plugin in LiveKit Agents does not support an enable_diarization option and does not emit speaker labels. Therefore the LLM will not automatically have speaker context from Deepgram via the plugin.
What that means for your flow
• You cannot prompt the LLM with "What did Speaker A say?" using diarization data from the Deepgram plugin because that plugin doesn't provide speaker IDs in its outputs.
• If you need true diarization (speaker-attributed transcripts) you have three practical options:
Options and examples
• Use a different STT plugin that supports diarization (recommended if you want seamless integration).
◦ Example: the Speechmatics STT plugin supports enable_diarization and returns speaker_id in its results. With Speechmatics, you can build prompts like:
▪︎ "Transcript:
Speaker 1: Hi, I need help with my account. Speaker 2: Sure—what's your account ID? Based on the above, summarize what Speaker 1 asked."
• This lets the LLM receive speaker-prefixed lines and answer with speaker-aware responses.
• Call Deepgram’s API outside of the LiveKit plugin (if Deepgram’s API supports diarization beyond the LiveKit plugin).
◦ Example flow:
i. Upload the meeting audio to Deepgram’s REST API with diarization enabled.
ii. Receive a diarized transcript with speaker labels.
iii. Construct a prompt that includes speaker-labeled lines and send that to the LLM, e.g.:
"Speaker A: …\nSpeaker B: …\nQuestion: What did Speaker A say about billing?"
• This rebuilds speaker context before you call the LLM.
• Simulate speaker context within your application (no true diarization).
◦ If you control participant metadata (e.g., microphone/participant IDs from LiveKit), you can tag turns yourself:
▪︎ Capture each participant’s audio/turn and prepend participant names to their transcribed text.
▪︎ Build the LLM prompt from those tagged lines.
◦ Note: this is session-turn tracking, not audio-based diarization, so it only works when participant-turn mapping is reliable.
Follow-ups I can help with
• If you want, tell me which approach you prefer (use Speechmatics, call Deepgram API directly, or simulate by participant metadata) and I’ll provide a concrete example prompt and a sample implementation outline for that path.
• If you want a sample prompt for the LLM given diarized text, say so and I’ll create one. Sources: Speechmatics STT plugin guide | LiveKit Documentation | Deepgram STT plugin guide | LiveKit Documentation | Deepgram STT | LiveKit Documentationstocky-oil-29870
02/17/2026, 1:09 PMtall-airline-16756
02/17/2026, 1:10 PMmin_interruption_duration, min_endpointing_delay (and the non-existent endpointing_ms in LiveKit Agents) interact, and whether your two example user speech patterns would be considered a false interruption.
Short summary
• endpointing_ms is not a LiveKit Agents parameter. Endpointing behavior is controlled by min_endpointing_delay (and related VAD settings).
• A "false interruption" only happens when speech is long enough to trigger an interruption but results in no transcribed words; then the system emits an agent_false_interruption event and can resume the agent.
• If a user’s utterance is shorter than min_interruption_duration, it won’t qualify as an interruption at all — so it won’t be counted as a false interruption.
Definitions (brief)
• min_interruption_duration (seconds): minimum speech duration required to count as a valid interruption.
• min_endpointing_delay (seconds): minimum time to wait after detected end-of-speech before finalizing the turn (affects endpointing responsiveness).
• False interruption: interruption that halted agent speech but yields no transcribed words; triggers agent_false_interruption and (if enabled) agent resumes after the false-interruption timeout.
Now let’s apply those facts to your two cases.
Case setup you gave
• Agent speaking.
• Settings you provided (interpreting your values as seconds where applicable):
◦ min_interruption_duration = 1.0 s
◦ min_endpointing_delay = 0.3 s
◦ endpointing_ms = 200 ms (note: not a LiveKit Agents parameter; treated below)
Case 1: user speaks for 0.5 s starting at t = 0
• 0.5 s < min_interruption_duration (1.0 s), so this speech is below the threshold to be considered a valid interruption.
• Outcome: The system will not register a valid interruption (it won’t stop the agent). This is NOT a false interruption — it simply didn’t meet the interruption-duration threshold.
Case 2: user speaks 0.8 s, pauses 200 ms, then speaks again
• Each continuous speech segment is evaluated against min_interruption_duration.
• First segment: 0.8 s < 1.0 s, so by itself it does not meet the interruption-duration threshold.
• The 200 ms pause is shorter than your min_endpointing_delay (0.3 s). Endpointing uses min_endpointing_delay to decide whether silence marks an end-of-speech for user input; because the pause is shorter than that, the VAD likely treats this as a continuation rather than a finalized endpoint.
• The resumed speech will be combined with the prior partial segment for ongoing VAD detection; if the combined continuous speech reaches >= 1.0 s, then an interruption could be triggered at that point.
• Outcome possibilities:
◦ If the total contiguous speech (counting the short pause as continuation) reaches >= 1.0 s before the agent is stopped, it can trigger an interruption.
◦ If no contiguous period ever reaches 1.0 s, no valid interruption occurs — therefore not a false interruption.
◦ A false interruption only occurs if speech did meet the interruption threshold (≥ min_interruption_duration), the agent was halted, and the STT produced no words.
Clarifying the role of your listed timings
• min_interruption_duration is the gatekeeper for whether a detected vocalization becomes an interruption at all.
• min_endpointing_delay controls how long silence must persist before finalizing an end-of-turn; short silences below that delay are usually treated as continuing speech.
• endpointing_ms is not used in LiveKit Agents — don’t rely on it for behavior here.
Concrete answer to your questions
• With your numbers, Case 1 (0.5s) is not a false interruption — it’s below the min_interruption_duration threshold and will not interrupt the agent.
• In Case 2, because each continuous speech segment is under 1.0s but the 200ms pause is shorter than min_endpointing_delay, the system will likely treat the voice as one continuing utterance. If that combined utterance reaches ≥ 1.0s, it can trigger a real interruption. If it never reaches 1.0s, it will not trigger an interruption and therefore not be a false interruption.
• A false interruption requires that an interruption actually happened (i.e., duration threshold met) and STT returned no words.
If you want
• I can show timeline examples with exact timings and when an interruption event would fire (visualized by timestamps).
• I can suggest parameter tweaks to make the system more or less sensitive to short user interjections (e.g., raise min_interruption_duration to reduce accidental interruptions, or lower min_endpointing_delay to finalize short user pauses faster).
Which follow-up would be most helpful — a timestamped timeline for Case 2 showing when VAD would trigger, or recommended settings based on the sensitivity you want?
Sources: VAD and turn detection configuration guide | LiveKit | Improving voice AI&#39;s turn detection with transformers | Turns overview | LiveKit Documentation