| Summary: | ASTERISK-08054: The two files produced by the Monitor application have diferent sizes and lengths, which produces unsynchronized recordings | ||
| Reporter: | Gerardo Costilla (geecox) | Labels: | |
| Date Opened: | 2006-11-02 14:58:30.000-0600 | Date Closed: | 2006-11-27 10:36:04.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_features |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | When monitoring a call with the Monitor Application, Asterisk creates two files (the two legs of a monitored call, the -in and -out files), however the files end up with different sizes and when the conversation is long, the size might so different that the resulting mixed wav file that I create using soxmix may be uncomprehensible because the lack of synchronization. When the conversation is longer than 20mn, the file lengths may differ as much as 20 seconds, which makes the final recording useless. From what I understand, several samples are dropped randomly and constantly from one of the channels and one of the wav files results shorter. This makes a lot of the recordings useless. ****** ADDITIONAL INFORMATION ****** At the moment I've figured out a work-around that works some times but diminishes the motion (talking speed) of the shorter file: Since the samples are dropped constanty, its ok to enlarge the shorter file in order to make it about the same length (play time) of the larger file. For example if clip-01-in.wav is about 30s and clip-01-out.wav is about 25s, then its OK to enlarge the second one about 5s. Mixing the files with soxmix will then produce a synchronized recording, yet slow-motion effect will appear in the voice of the file that was enlarged. The enlargement process can be made using sox. Nonetheless, when the lenght of the recording is larger thatn 20mn, then the procedure described above is not enough and even after applying the leght-emparejamiento with sox, the final mixed file will present synchronization problems. Here I include the way this bug behaves. I include information of the percentage that is missing in one of the files, which is worse as the lenght of the recording grows. For example, in a 5-min recording a 5% is not a problem at all, but in a 20-min recording a 5% means 60 seconds of delay in one of the channels, which makes the recording useless. In a sample of about 2737 recordings, the 92.58% (2534 recordings) both files are of exactly the same length; however, 4.20% (115 recordings) one of the files is 1% shorther and 1.32% (36 recordings) one of the files is 2% shorter, and so on, as the chart below shows. % dif recs count % of sample 0 2534 92,58% 1 115 4,20% 2 36 1,32% 3 18 0,66% >20 10 0,37% 4 8 0,29% 6 4 0,15% 5 4 0,15% 15 3 0,11% 17 1 0,04% 13 1 0,04% 12 1 0,04% 11 1 0,04% 7 1 0,04% 2737 100,00% | ||
| Comments: | By: jmls (jmls) 2006-11-03 03:36:52.000-0600 would you able to let us know of your setup specs (hardware / software etc) ? Thanks. By: Gerardo Costilla (geecox) 2006-11-09 10:31:16.000-0600 Asterisk is running on a HP Proliant LM350 with Fedora Core 3, 2 (two) Intel Xeons at 3.0 GHz, 4GB RAM and 132GB of HD. At the moment 30% of the HD's space is available. The box is running with only 10-20% CPU usage most of the time and handles about 60 calls simultaneously. This is the output of uname -a Linux tele1 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 i686 i386 GNU/Linux. By: Anthony LaMantia (alamantia) 2006-11-23 12:35:17.000-0600 this has nothing much to do with this bug (which still needs to be resolved) but have you considered using MixMonitor() rather then Monitor in situations where you want to mix both ends of the channel? By: wes (whoiswes) 2006-11-27 08:07:50.000-0600 see bug 8298 - there has already been a patch developed for this issue. http://bugs.digium.com/view.php?id=8298 By: Anthony LaMantia (alamantia) 2006-11-27 10:36:03.000-0600 the other entry in the bug tracker has a patch closing this one. | ||