[Asterisk-Dev] Help Debugging Dropped Call Audio

[Matthew Roth]

Mike Benoit wrote:

>Matthew,
>
>	If it helps, I have been dealing with this issue on about 5 different
>Asterisk boxes for the last year or more. Early v1.0 all the way up to
>v1.2. These boxes are all very low usage (couple lines max), but this
>problem happens consistently in every recording made by Monitor.

It helps greatly.  We've been trying to determine if it's an isolated 
problem by running test calls on various hardware platforms, network 
architectures, Asterisk versions, etc.  It's always been there, but we're 
still only one user out of thousands (millions?) and nobody else seems to be 
experiencing it.  If they are, it's going unnoticed or unreported.

Would it be possible to mail me a recording off list?  The pop is very 
distinct and listening to a call for it may be the simplest way to determine 
if we're experiencing the same problem.

>The weird thing though is if we listen to the recording in XMMS, the
>cracks/pops are terrible, and make it very difficult to listen to. But
>if I use the SOX package's "play" application, the cracks/pops
>disappear. I'm not sure if its just masking them, but recording sounds
>much better, and I haven't NOTICED problems of dropped audio.

We'll be distributing the recordings to our clients for quality assurance 
purposes, so we can't control what application they are being played back 
in.

>During the calls I can't determine that any audio is being dropped.

I hope you are correct.  I'm going to look at this problem as being strictly 
related to Monitor(), then work my way back.  There are simply too many 
variables to account for using the approach that assumes a related drop in 
call audio.

>Since using "play" or any other windows based media player that I have
>tried doesn't have this crack/pop issue, I haven't reported this problem
>to the mailing list at all.

That's interesting.  I experience the problem using Windows Media Player.  
Regardless, I wonder if other users are simply finding ways to deal with it.

>Let me know if you would like more information.

Certainly.

- What have you tried to solve the problem (ie. Disabling the Linux frame 
buffer, not running X windows, disabling hyperthreading, disabling ACPI, 
etc.)?
- What codec are you using for the calls?
- What format are the calls being recorded to?
- What call volumes do you experience the problem at?
- Are you recording the leg files directly to disk (we record to a RAM 
disk)?
- What is your hardware platform?
- What Digium hardware are you using?
- What is your Linux distribution?
- What is your kernel version?

>PS. This happens with SIP->SIP calls, AND SIP->ZAP calls.

I'll have to look into if these are all bridged using the same bit of code.

Thank you very much for your response.

Sincerely,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer