Asterisk 11.24.1 Garbled Audio

Home » Asterisk Users » Asterisk 11.24.1 Garbled Audio
Asterisk Users 12 Comments

Hi all

I am using asterisk 11.24.1 on a CentOS 5 machine. kernel 2.6.18 flavor.
(x86_64). I have about SIP 150 endpoints on it. when I send a message I’m getting garbled audio.

I used to have a single PRI card in the box – but something happened and that connection no longer worked. I removed the card and also removed the system.conf and chan_dahdi entries.

I am using ConfBridge in a PA kind of mode so all endpoints are muted.

how do I monitor any dahdi timing? (dahdi 2.11.1 complete) (libpri 1.5)

Network is 1G. Devices are 100Full connected to a 100Full switch. Server is a real server 95% idle when speaking.

Any suggestions on what to look at or how to resolve?



12 thoughts on - Asterisk 11.24.1 Garbled Audio

  • I found dahdi_test…

    dahdi_test Opened pseudo dahdi interface, measuring accuracy…
    99.999% 99.904% 99.974% 99.814% 98.070% 97.850% 99.985% 99.887%
    99.708% 99.899% 99.805% 99.708% 99.902% 100.000% 99.949% 99.883%
    99.891% 99.906% 99.784% 99.719% 99.827% 99.903%
    — Results after 22 passes –

  • Information on timing sources can be found here:

    As noted on that page, ConfBridge can use any timing interface Asterisk provides, and is not limited to the DAHDI timing interface. Generally, timerfd is a good timing interface.

    That aside, I would try to rule out external issues with the garbled audio before changing the timing source. Things like:
    – Analysis of the RTP traffic (along with potential jitter)
    – CPU utilization with an active conference (95% idle doesn’t mean that some core isn’t pegged)
    – Any potential transcoding issues or codec issues


  • Hi Matt – thanks.

    Looks like I am ONLY loading:
    res_timing_pthread res_timing_dahdi

    But I dont think the res_timing(x) is working on CentOS 5. res_timing_timerfd does not even seem to be compiled on this box.

    How do I tell for sure what its using and if its good. All I saw in the asterisk log was the two res_timing_pthread and res_timing_dadhi being loaded.

    Everything else is fine actually. It worked with the card, and withthout the card just sending audio to one endpoint has audio issues in a conference. The machine is doing nothign else at that time.



  • You’re probably running a version of the Linux kernel that doesn’t support timerfd, hence why it isn’t available.

    res_timing_pthread is … not very good. It exists as an absolute, last ditch fall-back for Asterisk to provide a source of timing when none exists. As such, and assuming you have ruled out all other sources of the garbled audio, then I’m really not surprised that it isn’t very effective.

    Your best bet would be to:
    – Provide a hardware timing source that res_timing_dahdi can use. IIRC, this should work even without a specific card, but does require the dahdi kernel module to be installed and available. (I could be wrong on the need for a physical card however, so your mileage may vary.)
    – Upgrade to a version of the kernel that res_timing_timerfd supports. That should be Linux 2.6.26 and glibc 2.8 or later.

    Personally, if I were in your shoes, I’d go with the latter. CentOS 6
    should be good out of the box, and CentOS 5 is pretty long in the tooth.


  • Hi,

    How can I double check which timer is currently is use in a running system ?
    core show settings doesn’t tell anything, if I’m not mistaken.


    2016-11-11 21:02 GMT+01:00 Matthew Jordan :

  • –qWwqv8G6kRguF0WMTGhlmxnjnleT8iUUF
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable


    Am 15.11.2016 um 17:52 schrieb Olivier:

    To determine which timing module is currently in use, you can take a look at “module show like timing”. There should be only one module with “use count” 1 – that’s the one that is currently used. If there is no call running, you can unload any additional timing module you don’t want to use to force Asterisk to use the only one left by simply doing “module unload res_….”.

    Also, please check in “core show settings” if internal timing is enabled or not. If it’s not, please enable it in asterisk.conf. The internal timing should be enabled by default, but if it’s not Asterisk might not use any timing module at all if RTP is being bridged between two ends of a call. Asterisk normally synchronises the RTP clocking to one end of the call. But if this RTP source is not realiable (jitter, packet loss, silence suppression…) you can end up having audio problems.



  • Date: Tue, 15 Nov 2016 17:52:07 +0100
    From: Olivier
    To: Asterisk Users Mailing List – Non-Commercial Discussion

    Subject: Re: [asterisk-users] Asterisk 11.24.1 garbled audio Message-ID:

    Content-Type: text/plain; charset=”utf-8″


    How about

    module show like timi


    I use DAHDI timing, and this command on my system it shows:

    module show like timi
    Module Description Use Count DAHDI Timing Interface 147
    1 modules loaded

    To get this in my modules.conf I specify (among other things):

    load => noload => noload =>

    I’m using, but should apply to you as well.

    Using DAHDI timing as I have had extensive problems under a heavily loaded system with both pthread and timerfd timing.

    Not sure if this still applies on your more recent Asterisk version though, but anyway – this is how you should be able to see what timing is being used on a running system.



  • module show like timing Module Description Use Count Status Support Level DAHDI Timing Interface 0
    Running core pthread Timing Interface 0
    Running extended Timerfd Timing Interface 0
    Running core
    3 modules loaded

    This is on asterisk 11.24.1 and dahdi-linux-complete 2.11.1, CentOS 7.2

    lsmod | grep dahdi dahdi 228088 0
    crc_ccitt 12707 1 dahdi

    PBX Core settings

  • –m1m09rAlwQ85BX0GpMo0laBRb0QD0BbgB
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable


    Am 17.11.2016 um 13:51 schrieb Jerry Geis:

    That’s a bit odd… On my Asterisk 11 setup, I see an entry “Internal timing” which is totally missing on your installation. You might want to try adding

    internal_timing = yes

    to the [general] section of your asterisk.conf and then stop and start your Asterisk.

    You can also try to unload all timing modules but “” and try if it makes things better. If it does, you can prevent res_timing_dahdi from being loaded in your modules.conf.



  • I found this comment:

    2014-04-08 21:20 +0000 [r411944-411974] Richard Mudgett <>

    * main/asterisk.c, /: Internal timing: Add notice that the -I and
    internal_timing option are no longer needed. Add notice messages
    during execution that the -I command line option and the
    astersik.conf internal_timing option are no longer needed. The
    internal timing functionality is now always enabled if there is a
    timing module loaded. NOTE: Since the command line options and
    the asterisk.conf config file are processed before the logging
    system is initialized, the messages are output to stderr. Change
    requested as a result of asterisk-dev list comments about the
    commit for ASTERISK-22846 that removed the -I and internal_timing
    options. Review:
    …….. Merged revisions 411964 from

    So on my 11.24.1 I dont think there is any such option any more.

    So now what??



  • On a newly installed idle 11.13.1 enabled system, I do also have:

    CLI> module show like timing Module Description Use Count pthread Timing Interface
    0 Timerfd Timing Interface
    2 modules loaded

    but when a call is ongoing :

    CLI> module show like timing Module Description Use Count pthread Timing Interface
    0 Timerfd Timing Interface
    2 modules loaded

    Thanks for mentioning “module show like timing”

    2016-11-17 13:51 GMT+01:00 Jerry Geis :