[asterisk-users] choppy sound with playback, background, etc... but not with musiconhold

[Matthew J. Roth]

Paco Brufal wrote:
> I have an asterisk 1.2.18 working fine, the only problem is that all
> applications that play audio, sound like "tremolo" or "vibrato", but
> musiconhold plays fine.
>
> The same audio file (wav, mp3, ...) works fine with Musiconhold()
> but not with Playback() or Background()...
>
> Do you know what is happening and how can I fix it? It's an only SIP
> system, no fxo/fxs cards.
>   
Paco,

You are in luck, because we just solved this problem.  It turned out to 
be a timing issue, which surprised me because I thought timing was only 
important for IAX trunks, meetme rooms, and music-on-hold.  Now I know 
that anything playing back audio files, except native music-on-hold, 
needs a reliable timing source.  This includes the Playback() and 
Background() applications, as well as queue announcements.

You have two options.  One of them is free and might work and the other 
will cost about $75 per server but should work reliably.  The first 
option is to use ztdummy, but there are a few points that you have to be 
aware of:

  1. The kernel version must be at least 2.6.13
  2. The kernel must be configured with a timer frequency of 1000 HZ
  3. The kernel must be configured to provide RTC interrupts
  4. The kernel must be configured with enhanced real time clock support

With a properly configured 2.6.13 or greater kernel, ztdummy will use 
the RTC instead of kernel jiffies.  This method is more accurate and 
should help alleviate your problems.  Just remember that if you install 
a new kernel you'll have to rebuild Zaptel against it.

We tried this and it helped, but it introduced another problem.  The 
Playback() application would intermittently lock up.  We are running on 
Dell PowerEdge 6850s, so I'm assuming the following issue documented at 
<http://www.voip-info.org/wiki/view/Asterisk+Zaptel+Installation> was 
the cause:
> Mar 2006: Specifically, with many Dell servers, RTC will fail to give 
> out interrupts, causing ztdummy to give no timing information. If you 
> are using ztdummy, and having issues with the Playback() command 
> causing the application to hang, then try the above step of disabling 
> acpi. In addition, a recompiled kernel, with HPET_EMULATE_RTC option 
> enabled, may solve the problem. (This option was removed in 2.6.13 kernel)
The second option is to install a TDM400P without any FXS/FXO modules as 
a timing source.  We've been running like this since Saturday and 
everything seems good so far.  In this case, there are two points to 
keep in mind:

  1.  The server must have an available PCI slot that is compatible with 
the TDM400P
  2.  The wctdm module must be passed the 'timingonly=1' parameter at load

Bare TDM400Ps are available from Atacomm at 
<http://voipstore.atacomm.com/Shops/ViewItem.aspx/27934028032-45624523776.htm> 
for under $75, which is pretty cheap for a "just works" solution.

Remember that you can use zttest to verify the accuracy of your timing 
source.  I ran it on each of the servers I installed a TDM400P in, and 
they all reported an average accuracy of better than 99.99%.  Digium 
recommends an accuracy of at least 99.98%, which ztdummy using the RTC 
wasn't able to provide.

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer