[asterisk-bugs] [Asterisk 0013005]: Recording speed too fast (running BRI B410P)

Wed Oct 8 10:07:45 CDT 2008

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13005 
====================================================================== 
Reported By:                alexb_uk
Assigned To:                putnopvut
====================================================================== 
Project:                    Asterisk
Issue ID:                   13005
Category:                   Applications/app_mixmonitor
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-07-07 05:12 CDT
Last Modified:              2008-10-08 10:07 CDT
====================================================================== 
Summary:                    Recording speed too fast (running BRI B410P)
Description: 
Hi,

I have been asked by Digium support to raise a bug against Mixmonitor for
making corrupt recordings in the latest version of Asterisk (1.4.21.1 and
1.4.21).

The bug does not appear when running 1.4.19.2 (with or without the latest
Zaptel drivers).

The recordings are playing back at high speed and with very bad quality.

I'm not the only person seeing this issue:
http://forums.digium.com/viewtopic.php?t=20985

Someone on the forum claims this bug has previously been raised and fixed
but sorry I could not locate it in Mantis.

Just to note I have tested the original WAV files prior to converting them
to MP3 and the issue remains.

The audio on the call itself is near perfect.

There are no errors in the logs / on the console.

Hardware:
  Digium B410P card on BT ISDN2e lines (UK).

Example Command:
   [Jul  3 11:06:20] VERBOSE[29391] logger.c:     -- Executing
[s at macro-record:19] MixMonitor("mISDN/11-u10",
"/tmp/03072008-110620--IN.wav||/usr/local/bin/wav2mp3
"/tmp/03072008-110620--IN.wav" "03072008-110620--IN.mp3" "1215079580.4" "0"
"X"") in new stack

If anyone is kind enough to look into this issue but doesnt have access to
a BRI setup then please let me know and I can provide remote access to a
server that does.

I could be incorrectly assuming this is related to BRI as I would have
thought this issue would have been found already if it happened on T1/E1
lines.  I do have access to an E1 line although it will take me a little
time to update a server and test.  Please let me know if this would be
helpful.

Thanks for any help.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012837 Chanspy audio is delayed or lost
====================================================================== 

---------------------------------------------------------------------- 
 (0093362) putnopvut (administrator) - 2008-10-08 10:07
 http://bugs.digium.com/view.php?id=13005#c93362 
---------------------------------------------------------------------- 
Here's a detailed explanation of why this problem is occurring. It's going
to require a bit of background about how audiohooks work in Asterisk, so
bear with me here.

An audiohook contains two buffers where slinear samples are stored. These
buffers are referred to as "slinfactories." One slinfactory is for audio
read from the channel and the other is used for audio written to the
channel. Each time audio is written into one of the slinfactories, the
audiohook triggers a signal which tells MixMonitor to read from the
factories. This read operation grabs 20 ms of audio from each factory
(assuming that much is available in each slinfactory), mixes the audio, and
applies any volume adjustments necessary. Then MixMonitor takes the audio
and writes it to whatever file the recording is stored in.

Issue http://bugs.digium.com/view.php?id=12296 was opened because if one of the
slinfactories was to build
up many samples of audio before the other were to get any, then when
MixMonitor was able to read 20 ms of audio from both slinfactories, the
audio would be out of sync. The fix for this was to add logic when writing
to a slinfactory such that if the time between now and the previous write
to that factory is greater than the number of milliseconds of audio
currently available in the other slinfactory, then all of the audio is
removed from both slinfactories prior to writing the new audio in. These
flushed samples are what is missing from the recording and causing it to
sound "fast."

So why does this happen for some people (especially those with B410P's)
and not others? Well, in the case of the B410P, we get somewhat "odd"
packetization of audio. In my case, one of the slinfactories was fed a
constant input of 20ms of samples, whereas the other would usually get 12
or 16 ms of audio. This meant that whenever we would write to the
slinfactory getting 20ms of audio every time, this meant that the check I
mentioned in the previous paragraph would cause the audio in both
slinfactories to get flushed nearly every time. This is because in the 20
ms between writes to the constant slinfactory, we would see only 12 or 16
ms of audio in the other factory most of the time. 

While I agree with the logic introduced in
http://bugs.digium.com/view.php?id=12296 to some extent, the
problem appears to be that it is too intolerant of small differences
between the slinfactories and that a tolerance factor needs to be added to
account for this. This is my plan for fixing the issue. I will do some
local testing and when I have a patch ready for general testing, I will
post it here.

Thanks for your patience on this one. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-08 10:07 putnopvut      Note Added: 0093362                          
======================================================================