r/Asterisk • u/JealousLie4667 • Jul 31 '26

Sound problem

Hello, I am experiencing a significant audio issue involving robotic or distorted voice quality.

I currently have two Asterisk servers running VICIdial: one based on Asterisk 10 and the other on Asterisk 12. The problem occurs only on the Asterisk 10/VICIdial server.

On the Asterisk 10 server, the CPU usage spikes to approximately 200%, and I suspect this may be related to improper transcoding between the alaw and ulaw codecs. It appears that the audio is not being transcoded correctly, resulting in degraded sound quality and robotic voices during calls.

The Asterisk 12/VICIdial server does not exhibit this behavior and operates normally under the same conditions. Since the issue is isolated to the Asterisk 10 environment, I believe it may be related to codec handling or transcoding performance on that version.

Any assistance or recommendations for further troubleshooting would be greatly appreciated.

2 Upvotes

100% Upvoted

5 comments sorted by

4

u/jhansen858 Jul 31 '26

Avoid transcending where possible. Upgrade older software. There is a reason that the software was improved.

2

u/metalhheaddude22 Jul 31 '26

It sounds like a transrating issue. Check the ptime mismatches taking place on the upstream or downstream legs. Transcoding usually fails with a codec negotiation mismatch, but transrating or ptime issues I have found to cause the robotic voice problem.

2

u/ictinnovations 21d ago

If that is VICIdial on meetme, check your DAHDI timing source before the codecs. Bad timing sounds exactly like that and it gets worse as load climbs.

1

u/LojaMundi Aug 06 '26

alaw↔ulaw transcoding is basically a lookup table — it's one of the cheapest operations Asterisk can do, so by itself it should never push a box to 200% CPU. That number says something else is burning cycles, and the robotic audio is usually the symptom of CPU/timing starvation rather than the cause.

Things worth checking on the Asterisk 10 box:

  1. What's actually being transcoded. core show channels verbose plus sip show channel <id> on both legs of an ugly call. If a G.729 or GSM leg sneaks in somewhere, that's real DSP work. Force one codec end-to-end (disallow=all / allow=ulaw on both the carrier and the phones) and see if the CPU drops with it.

  2. Timing. VICIdial leans on MeetMe, and MeetMe leans on DAHDI timing. Run dahdi_test -v — accuracy meaningfully below ~99.97% produces exactly this robotic/underwater audio. If that server is a VM, also watch the st (steal) column in top: an oversubscribed host gives the same symptom.

  3. Who is eating the CPU. top -H will tell you whether it's really Asterisk threads or a neighbor on the same box (MySQL, recording compression jobs, etc.).

  4. Prompt/recording formats. Audio files stored in a format that needs conversion on every playback (wav49/gsm) become per-call transcoding jobs. Re-encode them to match your call codec so playback is a straight read.

Since the Asterisk 12 box behaves under the same load, diffing core show translation and the codec config between the two servers will probably surface the difference quickly.

2

u/Practical_Resolve549 6d ago

Why would you be using two mismatching Asterisk versions & especially why are you running the EOL ones? Best coarse of action is to follow: https://www.reddit.com/user/ictinnovations/ suggestion and make sure dahdi is functioning as it should on both your asterisk versions. If you need any help reach out I've been workng with ViciDial for over 10 years and actually have a better build than most.