Diagnosing choppy or robotic audio on agent calls
Choppy, robotic, or garbled call audio almost always comes from the RTP path: jitter, packet loss, a codec mismatch, or a CPU-starved dialer.
Agents report that calls sound underwater, robotic, or full of dropouts, but the call still connects and the customer is on the line. That tells you the signalling worked and the problem lives in the audio stream, not the call setup. Garbled audio is almost always a media-path problem, and there are only a handful of usual suspects. Working through them in order saves you from guessing.
Signalling versus the audio stream
Once a call is set up, the actual voice travels over RTP — the real-time stream of small audio packets that carries each direction of the conversation. If those packets arrive late, out of order, or not at all, the audio breaks up even though the call stays connected. So when the call works but sounds bad, you are debugging the RTP path, not the dialer's call logic.
Jitter and packet loss
Two network problems produce most choppy audio. The first is Jitter — packets arriving with uneven spacing — which makes speech sound shaky or warbly. The second is Packet loss, where packets never arrive at all, which produces gaps, clicks, and clipped words. A useful single number is the MOS (mean opinion score) score, the mean opinion score that rates call quality from roughly 1 to 5. If your MOS sits well below 4, the network between the box and the endpoint is the place to look first, not the dialer.
Codec mismatch
A Codec is the scheme that compresses and decompresses the audio. The two you will meet most are G.711 codec, which is uncompressed and high quality but bandwidth-heavy, and G.729 codec, which is compressed and light on bandwidth but more fragile when packets go missing. Robotic audio often shows up when a call is transcoded between codecs more than once, or when a low-bandwidth codec runs over an already lossy link. Keeping the codec consistent between agent, dialer, and carrier removes a whole class of garbling.
CPU on the dialer itself
Audio also turns choppy when the dialer is starved for CPU. Every active call is a Channel on the box, and Asterisk has to copy, time, and sometimes transcode audio for each one in real time. If the server is overloaded — too many concurrent calls for its cores, a runaway process, or transcoding everything to a compressed codec — the audio it produces will stutter even on a clean network. Watch load average and per-core usage during a bad stretch.
Narrowing it down
flowchart TD
A[Audio is choppy or robotic] --> B{Call connected fine}
B -->|Yes| C[Media path problem not signalling]
C --> D{MOS low or packet loss high}
D -->|Yes| E[Network jitter or loss between box and endpoint]
D -->|No| F{Same codec end to end}
F -->|No| G[Fix codec mismatch or double transcode]
F -->|Yes| H{Dialer CPU healthy}
H -->|No| I[Reduce concurrent channels or add cores]Where to go next
If the slowness shows up as delay rather than garbling, the culprit is usually round-trip Latency instead of loss, covered in diagnosing high agent latency. For the full first-response checklist, see the VICIdial troubleshooting playbook.
If you would rather not size cores and tune codecs by hand, VICIfast runs a hardened, managed VICIdial box that is live in under 40 seconds. See our plans and pricing.
About VICIfast LLC
VICIfast LLC operates a managed VICIdial hosting + BYOI service for outbound and inbound call centers. We run the dialers, the carriers, the recordings pipeline, and the compliance plumbing so operators don’t have to.
Citing this article
VICIfast Engineering. “Diagnosing choppy or robotic audio on agent calls”. VICIfast LLC, June 25, 2026. Retrieved from https://vicifast.com/blog/diagnose-choppy-or-robotic-audio
Have questions?
Related posts
You might be interested in
VICIfast newsletter
Liked this? Get the next one in your inbox.
We ship the kind of stuff you just read — concrete, numbers-first, no drip. One email when a new post goes live. Unsubscribe in one click.
Comments
No comments yet — be the first.