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

[Asterisk Bug Tracker]

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-10 09:09 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0093469) putnopvut (administrator) - 2008-10-10 09:09
 http://bugs.digium.com/view.php?id=13005#c93469 
---------------------------------------------------------------------- 
Dark_Schneider971: If you don't mind doing so, could you set the debug
level to at least 1 and get the calls to go fast again? When this starts
happening, check the console to see if there are a lot of debug messages
that say "Flushing audiohook <some hex value> so it remains in sync." If
these messages are appearing, then my fix needs some work because it's
still the same area causing trouble. If not, then something else is
contributing after a long time and I'll need to see the console output to
try to figure out what's going wrong. Since I now have a setup which could
cause the issue to start with, I can also attempt to reproduce the problem
again.

In answer to where the 100 ms value comes from, it was a suggestion made
to me by Steve Davies, who said that if audio becomes out of sync by 100
ms, you won't really notice it. The idea of dynamically setting the
tolerance based on the packetization of the media seems like it could be a
good idea, but it may require more overhead than is worth using in order to
do it, especially if we use the suggestion of dynamically increasing the
tolerance under load.

By the way, if I'm going to try to make this happen here, it would help to
know what technologies were being used when you got the recordings to speed
up as well as what codecs were being used. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-10 09:09 putnopvut      Note Added: 0093469                          
======================================================================