https://livekit.io logo
Join Slack
Powered by
Hi, we are getting a big spike in users ciomplaini...
# ask-ai
p
Hi, we are getting a big spike in users ciomplaining that their sessions are getting cut, and for what we have been investigating it seems to be an echoing issue, the agent hears itself through the speakers and then it interrupts what it's saying. Most of the complaints seem to come from Android users. We are currently using: • Python ◦ Livekit agents 1.4.2 ◦ Livekit 1.1.2 ◦ Livekit Noise Cancellation 0.2.5 ▪︎ 
AudioInputOptions(noise_cancellation=noise_cancellation.BVC())
• Android ◦ Livekit 2.20.2 • iOS ◦ Livekit 2.7.2 Is it possible this has something to do with the backend noise cancellation plugin? Should we instead use instead Client noise cancellation using the Krisp filter?
t
Thanks for reaching out, Marcel. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — this is a great, detailed report and I hear the urgency. I’m responding to your question about whether the backend BVC noise cancellation is causing the interruptions and whether switching to client-side Krisp will fix the issue. Short answer • The backend 
BVC()
noise cancellation is not causing the echo interruptions, but it also cannot prevent them. • Enabling Krisp on the client will not reliably stop echo-induced self-interruption and can sometimes make things worse. • The root problem is acoustic echo (the agent’s speaker output being re-captured by the device microphone). The reliable fixes are on the client side: acoustic echo cancellation (AEC), headset use, and turn/VAD tuning or manual turn control. Why backend noise cancellation (BVC) is not the fix • The backend BVC plugin runs before STT and is designed to suppress background noise and non-primary speakers, but it cannot distinguish the agent’s own voice when that voice is re-recorded through the device speaker. Once the agent audio appears as “incoming speech” from the mic, BVC treats it like speech and cannot reliably suppress it to avoid false turn transitions. • That means BVC isn’t causing the echo, but it is insufficient to prevent echo-triggered false activations. Why Krisp client-side noise suppression won’t reliably solve this • Krisp reduces background noise in the captured audio stream but does not act as an acoustic echo canceller that is aware of the local speaker output. Echoed agent audio can still be picked up by the mic and may trigger VAD or end-of-utterance logic. • Turning Krisp on is unlikely to prevent the agent’s own voice from being interpreted as user speech and may not improve the false-trigger rate. What to do instead — recommended actions (prioritized) 1. Short-term mitigation (fast, high impact) ◦ Encourage or require headset use for Android users (wired or Bluetooth with proper handsfree profile). Headphones prevent speaker-to-mic bleed and are the single most effective mitigation. ◦ Advise users to lower speaker volume or move microphone away from speaker if headsets are not possible. 1. Client-side AEC and audio routing (platform-specific) ◦ Ensure Android devices are using the platform’s AEC where available (Android’s built-in AEC works when proper audio routing and hardware profiles are used). This reduces speaker-to-mic echo more reliably than noise-suppression models. ◦ Verify microphone and speaker routing on affected devices to confirm AEC is active and supported by the device. 1. Turn/VAD tuning and detection strategy ◦ Increase robustness of VAD/end-of-utterance settings (for example, lengthen 
min_silence_duration
or similar parameters) so brief echoes don’t trigger turn ends or user commits. ◦ Consider switching to manual or hybrid turn control (for example, 
turn_detection = "manual"
and using 
commit_user_turn()
or a confirmation flow) so the system only commits turns when you explicitly decide the user finished speaking. This prevents false activations from short echoed blips. 1. Monitoring & targeted triage ◦ Focus on Android first: collect device model, Android version, and whether users are on headphones vs speakers. Echo problems are often device-dependent and worse on low-end devices or older Android versions. ◦ Roll out client-side guidance or forced headset policy for the most impacted user segments while you collect data. Why this combination works • AEC and headsets stop the agent’s voice from reentering the mic at the source. • VAD/turn tuning prevents brief echoes that do get through from causing immediate interruptions. • Manual/hybrid turn control gives you deterministic control when automated detection is unreliable. If you’d like, I can help with next steps: • Suggest specific VAD/turn parameter values to try (tell me what 
min_silence_duration
and turn settings you currently use). • Draft a short support message to send Android users recommending headsets and volume checks. • Outline a diagnostic checklist (what device info to collect, logs to capture) to identify which Android models are most affected. Which would you like to try first — VAD tuning suggestions, an Android diagnostic checklist, or a short user-facing guidance message? Sources: Choosing the right noise cancellation for your agent | LiveKit | Troubleshooting STT not picking up utterances | LiveKit | SIP Telephony and Encryption | How does end-of-utterance detection work in conversations? | Turns overview | LiveKit Documentation
p
This is our VAD config right now:
Copy code
job_process.userdata["vad"] = silero.VAD.load(
            min_speech_duration=0.2,
            min_silence_duration=2,
        )
t
Thanks — this is helpful. I’m responding to your VAD config and the echo-interruption problem on Android. What I see • Your current VAD uses 
min_speech_duration=0.2
and 
min_silence_duration=2
. • With echoes, very short reflected snippets of the agent’s voice can look like valid speech (0.2s is short), and a long 
min_silence_duration
of 2s may cause the system to wait a long time before deciding a user stopped speaking or before committing a turn, which interacts poorly with false short activations and can make interruptions feel abrupt when the system finally switches. Concrete tuning suggestions to reduce echo-triggered false activations 1. Increase minimum speech duration ◦ Set 
min_speech_duration
to a larger value so very short echoes are ignored. ◦ Try 0.4–0.6 seconds as a first step. This ignores blips shorter than ~400–600ms that are likely echoes. 1. Reduce or adapt min_silence_duration ◦ A long 
min_silence_duration=2s
delays end-of-speech detection, which can make the turn handling brittle. Try lowering to 0.6–1.2 seconds. ◦ If you rely on the long silence to avoid chopping user speech, consider alternative turn control (see #4) instead of a long global silence. 1. Add a debounce / confirmation for turn changes ◦ Require two consecutive VAD frames above threshold before treating it as a new user turn (simple frame-based debounce). ◦ This prevents single-frame echoes from toggling state. 1. Consider manual or hybrid turn commit ◦ If false activations persist, use manual/hybrid turn handling: keep automatic detection conservative (higher thresholds, longer min_speech_duration) and call 
commit_user_turn()
only after you’ve confirmed user speech or a higher-confidence condition. 1. Combine with device-level checks ◦ Only enable looser VAD settings (short min_speech_duration) for headphone users. Use signaling from the client that indicates headset vs speaker mode and apply more conservative VAD on speaker mode. Suggested trial values (start here and iterate) • Experiment A (conservative): ◦ 
min_speech_duration = 0.5
◦ 
min_silence_duration = 0.8
◦ Add debounce: require 2 consecutive positive frames to start a segment • Experiment B (balanced): ◦ 
min_speech_duration = 0.4
◦ 
min_silence_duration = 1.0
◦ Debounce: 2-frame confirmation What to measure when testing • False positive rate (how often system starts a user turn when the agent is talking). • Latency to commit a legitimate user turn (does the change add unacceptable latency?). • User-reported interruption frequency on Android vs iOS after changes. Next steps I can help with • Drafting code snippets to implement debounce + conditional VAD based on headset detection. • A small A/B test plan to roll changes to a subset of Android users and collect metrics. • A short diagnostic checklist you can send to affected users to capture device model, Android version, and whether they were using speakers or headphones. Which would you like to try first — suggested code for debounce + headset-aware VAD, or an A/B test plan to validate the new VAD settings?
2 Views
Open in Slack
PreviousNext
Powered by