Issues with user audio cutting out
# support
i
Having some issues on the weekly channel around Feb 25 9PM EST with user audio cutting out or getting choppy or the user speaking but the AI just not hearing it: call ID: 019c97a8-5379-7335-82d0-2521f6e8016d timestamp: 0:57 onwards detailed description: the user's audio cut out mid-sentence, actually you can hear a little staticy sound coming in around 0:58 before it goes out completely. expected behavior: user finishes sentence. call ID: 019c97ac-5d0c-7991-9f1b-d9ccd53e00a3 timestamp: 2:26 detailed description: even though the user answered the question (2:14-2:23) clearly, the AI just responds "Sorry. I didn't catch that." and re-asks the question as if it didn't hear it at all. expected behavior: AI hears the answer from 2:14-2:23 and moves to the next question. less clear if this is due to VAPI issue: call ID: 019c97ac-5d0c-7991-9f1b-d9ccd53e00a3 timestamp: 1:20 detailed description: User answers question at 1:11 but the sound is low volume and cutting out, the AI doesn't hear it and says the idle message expected behavior: AI hears the answer and moves on.
v
To quickly diagnose your audio cutout issues, navigate to
Observe > Call Logs
in your [Vapi dashboard](https://dashboard.vapi.ai/), select the affected call IDs, and review the transcript and audio at the specified timestamps.
This will help you pinpoint where the audio dropped or was not recognized, and you can also check for any error messages or tool execution issues directly in the log view. Tip: Include these findings if you need to escalate to support for faster resolution. [See Debugging Guide](https://docs.vapi.ai/debugging) Source: - [Debugging voice agents](https://docs.vapi.ai/debugging)
c
Hi Ifeanyi, thanks for sharing your details. Our team will look into it and get back to you soon with an update.
f
This appears to be an audio ingestion issue where user speech is either cutting out or not being reliably detected. The static before the cutoff suggests a possible upstream audio or WebRTC stream interruption. In the second and third cases, the AI response indicates the audio may have been too low or dropped below the speech-detection threshold. This may be related to input gain, network stability, or VAPI audio handling
c
Hi Ifeanyi, I've analyzed all three audio issues across the two call IDs. Here's a summary: Call 1 (
019c97a8-5379-7335-82d0-2521f6e8016d
) — Audio cut out at 0:57 Root Cause: VAD (Voice Activity Detection) falsely detected "speech stopped" during a natural pause in a 30+ second long user utterance, or Deepgram STT session timed out. The transcript shows the user's sentence ended abruptly mid-thought: "...from station 8 44 plus 20 to station". Fix: Increase
minSpeechDurationMs
in VAD settings and review Deepgram streaming timeout. Call 2 (
019c97ac-5d0c-7991-9f1b-d9ccd53e00a3
) — "Didn't catch that" at 2:26 Root Cause: Premature endpointing. The user started hesitantly ("Well, it makes it...") with low confidence (0.66), and the endpointing buffer committed to a "didn't catch that" response BEFORE the user finished speaking. The final transcript arrived 840ms later with the complete answer ("Well, the mixer showed up."). Fix: Increase endpointing patience to 150-200ms, implement partial transcript buffering, and lower the confidence threshold for triggering clarification requests. Call 3 (same call) — Low volume at 1:20 Root Cause: User's audio volume was below VAD confidence threshold, causing the system to treat it as silence and trigger the idle timeout. Fix: Lower VAD
confidenceThreshold
, consider audio level normalization, and replace idle timeout with "trouble hearing you" message. General Recommendations 1. Enable Krisp denoiser for PSTN calls 2. Increase endpointing delay to 150-200ms 3. Implement adaptive endpointing based on question type 4. These are all configuration changes — no code modifications needed Full details posted in the Slack thread.