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

Tue Oct 14 17:46:39 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:                     ready for testing
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-14 17:46 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0093661) putnopvut (administrator) - 2008-10-14 17:46
 http://bugs.digium.com/view.php?id=13005#c93661 
---------------------------------------------------------------------- 
Okay, so it appears that everyone so far has reported that the tolerance
patch has worked for them. The only exception to the good reports is
Dark_Schneider971's report that the problem exists still on long calls.

I think it would be appropriate, then, for me to commit the changes so
that the problem will, for the most part, be gone. I won't close this
issue, though, until the problem is fully resolved. This will require
either Dark_Schneider971 or someone else who still experiences the issue to
upload console output as I instructed in note
http://bugs.digium.com/view.php?id=13005#c93469.

Also, I realize I never remarked regarding stevedavies' suggestion
regarding reclocking the audio based on packetization rates of the
channels. The truth is, this should not be necessary. Raw samples are
stored in the slinfactories, and we always pull 20 ms of audio from both.
If one or both does not yet have 20ms of audio, we delay until the next
time mixmonitor triggers to attempt reading audio from both again.
Reclocking shouldn't be necessary since we pretty much have a built-in
smoother for the audio. We can afford to do this since it's not vital that
the mixmonitor recordings are kept exactly up-to-date based on the audio
which has been passed through Asterisk. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-14 17:46 putnopvut      Note Added: 0093661                          
======================================================================