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:

  https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

  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

  Matt

• 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.

  Thanks,

  Jerry

• 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.

  Matt

• 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.

  Regards

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

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

  Hi,

  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.

  Max

  –qWwqv8G6kRguF0WMTGhlmxnjnleT8iUUF

• 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 res_timing_dahdi.so DAHDI Timing Interface 147
  1 modules loaded

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

  load => res_timing_dahdi.so noload => res_timing_pthread.so noload => res_timing_timerfd.so

  I’m using 1.8.32.3, 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.

  Regards

  Stefan

• Why not just timing test It shows the timer used

• module show like timing Module Description Use Count Status Support Level res_timing_dahdi.so DAHDI Timing Interface 0
  Running core res_timing_pthread.so pthread Timing Interface 0
  Running extended res_timing_timerfd.so 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

  Hi,

  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 “res_timing_timerfd.so” and try if it makes things better. If it does, you can prevent res_timing_dahdi from being loaded in your modules.conf.

  Max

  –m1m09rAlwQ85BX0GpMo0laBRb0QD0BbgB

• I found this comment:

  2014-04-08 21:20 +0000 [r411944-411974] Richard Mudgett < rmudgett@digium.com>

  * 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: https://reviewboard.asterisk.org/r/3423/
  …….. Merged revisions 411964 from
  http://svn.asterisk.org/svn/asterisk/branches/1.8

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

  So now what??

  Thanks,

  Jerry

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

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

  but when a call is ongoing :

  CLI> module show like timing Module Description Use Count res_timing_pthread.so pthread Timing Interface
  0
  res_timing_timerfd.so Timerfd Timing Interface
  1
  2 modules loaded

  @Max:
  Thanks for mentioning “module show like timing”

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