Re: [Asterisk-Users] Skips and Pops in Call Recordings
Matt Florell wrote: Hello, Need some more information here: - hardware specs (including what kind of hard drives?) The Asterisk server is a Dell PowerEdge 6850 with the following specs. Please note that we are NOT recording to the hard drive. We are recording to a RAM disk as detailed here (http://voip-info.org/wiki/view/Asterisk+Dimensioning) under the heading 512 simultaneous SIP-to-SIP calls with Digital Recording. Unfortunately, the scalability tests we did at that time assumed that if call quality was good, so was the quality of the recording. Processor: Quad Intel Xeon 3.16GHz/1MB Cache Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk) Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored) Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver: megaraid_mm, megaraid_mbox) Everything else: http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf - Linux kernel version 2.6.12-1.1376_FC3smp (Fedora Core 3). - running Xwindows? No. - Asterisk version ABE-A.2-beta (Asterisk Business Edition A.2 beta). - kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) Calls originate on the PSTN and are handled by a Cisco AS5400 Universal Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls from TDM channels to VoIP (SIP) channels before sending them to Asterisk. The Asterisk dialplan then routes them to one of our agents, who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls are SIP-to-SIP, with absolutely no protocol bridging or transcoding occurring on the Asterisk server. The Asterisk server handles the following major tasks: - Routing calls through the dialplan to (dynamic) agents in the appropriate queues. - Adding/removing agents to/from queues via AddQueueMember and RemoveQueueMember (NO static agents!). - Recording calls via the Monitor application directly to RAM disk. Calls are moved to a remote machine for mixing. - ChanSpy-based quality assurance of calls. Neither ChanSpy nor the quality of the calls themselves is affected by the problem. - how many recordings at once Anywhere from 5 to 30 concurrent recordings. This is not our planned peak, but it's where we've experienced the problem so far. We have not yet determined if the number of concurrent recordings is an issue, but we are considering it. We also haven't determined if the problem gets worse as the number of recordings increases, but it definitely exists throughout that entire range. In my experience, HyperThreading does not cause recording problems, it's usually a disk issue. When we had issues, switching to fast SCSI drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all of our problems(skips and clicks/pops) The disk issues also directly interfere with call quality, as our previous scalability tests showed. Digium seems to think that the issue is scaling (some resource contention that causes a bit of audio to be unavailable when the write occurs). I see their point, but given our hardware and the current call volume I'm not completely sold on it. Could it be a configuration issue (file handles, interrupts, etc...)? MATT--- Colin Anderson wrote: Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today, 1482 calls!) of various length on my Netfinity with the onboard IBM RAID controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the other Matt indicated, maybe what is needed here is an intelligent controller to offload some of the chore. No definite solution here, but at least it's another data point to compare. I appreciate any information contributed by list users. It's by far the most valuable resource available to me. On 12/12/05, Matt Roth [EMAIL PROTECTED] wrote: List users, I'm using the Monitor application to record calls. Most of the recordings are audible, but contain skips accompanied by a popping sound. Sometimes they are isolated, sometimes they appear in groups. Call quality is excellent and seems unaffected by whatever is causing this problem. If anyone has experienced this problem before, I'd appreciate if you'd share what the source was and any tips on eliminating it. I contacted Digium tech support and they suggested turning off hyperthreading. I have done that, but I won't know if it improved things until tomorrow. The machine is running at a moderate call volume and is always at least 90% idle. I'm not seeing any Avoided deadlock messages in the logs. If you need any more information, I'd be happy to provide it. Thank you, Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] Skips and Pops in Call Recordings
What codec are the calls? What codec are you recording in? I would try some non-Dell hardware, I would also try a less bloated Linux Distro, something like Slackware, just to see if that had any effect. And make sure you use the megaraid2 linux drivers. MATT--- On 12/13/05, Matt Roth [EMAIL PROTECTED] wrote: Matt Florell wrote: Hello, Need some more information here: - hardware specs (including what kind of hard drives?) The Asterisk server is a Dell PowerEdge 6850 with the following specs. Please note that we are NOT recording to the hard drive. We are recording to a RAM disk as detailed here (http://voip-info.org/wiki/view/Asterisk+Dimensioning) under the heading 512 simultaneous SIP-to-SIP calls with Digital Recording. Unfortunately, the scalability tests we did at that time assumed that if call quality was good, so was the quality of the recording. Processor: Quad Intel Xeon 3.16GHz/1MB Cache Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk) Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored) Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver: megaraid_mm, megaraid_mbox) Everything else: http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf - Linux kernel version 2.6.12-1.1376_FC3smp (Fedora Core 3). - running Xwindows? No. - Asterisk version ABE-A.2-beta (Asterisk Business Edition A.2 beta). - kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) Calls originate on the PSTN and are handled by a Cisco AS5400 Universal Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls from TDM channels to VoIP (SIP) channels before sending them to Asterisk. The Asterisk dialplan then routes them to one of our agents, who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls are SIP-to-SIP, with absolutely no protocol bridging or transcoding occurring on the Asterisk server. The Asterisk server handles the following major tasks: - Routing calls through the dialplan to (dynamic) agents in the appropriate queues. - Adding/removing agents to/from queues via AddQueueMember and RemoveQueueMember (NO static agents!). - Recording calls via the Monitor application directly to RAM disk. Calls are moved to a remote machine for mixing. - ChanSpy-based quality assurance of calls. Neither ChanSpy nor the quality of the calls themselves is affected by the problem. - how many recordings at once Anywhere from 5 to 30 concurrent recordings. This is not our planned peak, but it's where we've experienced the problem so far. We have not yet determined if the number of concurrent recordings is an issue, but we are considering it. We also haven't determined if the problem gets worse as the number of recordings increases, but it definitely exists throughout that entire range. In my experience, HyperThreading does not cause recording problems, it's usually a disk issue. When we had issues, switching to fast SCSI drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all of our problems(skips and clicks/pops) The disk issues also directly interfere with call quality, as our previous scalability tests showed. Digium seems to think that the issue is scaling (some resource contention that causes a bit of audio to be unavailable when the write occurs). I see their point, but given our hardware and the current call volume I'm not completely sold on it. Could it be a configuration issue (file handles, interrupts, etc...)? MATT--- Colin Anderson wrote: Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today, 1482 calls!) of various length on my Netfinity with the onboard IBM RAID controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the other Matt indicated, maybe what is needed here is an intelligent controller to offload some of the chore. No definite solution here, but at least it's another data point to compare. I appreciate any information contributed by list users. It's by far the most valuable resource available to me. On 12/12/05, Matt Roth [EMAIL PROTECTED] wrote: List users, I'm using the Monitor application to record calls. Most of the recordings are audible, but contain skips accompanied by a popping sound. Sometimes they are isolated, sometimes they appear in groups. Call quality is excellent and seems unaffected by whatever is causing this problem. If anyone has experienced this problem before, I'd appreciate if you'd share what the source was and any tips on eliminating it. I contacted Digium tech support and they suggested turning off hyperthreading. I have done that, but I won't know if it improved things until tomorrow. The machine is running at a moderate call volume and is always at least 90% idle. I'm not seeing any Avoided deadlock messages in the logs. If you need any more information, I'd be
Re: [Asterisk-Users] Skips and Pops in Call Recordings
Matt, The calls are u-Law. The format of the recordings is PCM. Is this correct to prevent transcoding the recording? We've noloaded all other codecs, so I don't believe that transcoding is occurring. I've only ever seen "show translation" generate the following output: immlx15*CLI show translation Translation times between formats (in milliseconds) Source Format (Rows) Destination Format(Columns) g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex ilbc g723 - - - - - - - - - - - gsm - - - - - - - - - - - ulaw - - - - - - 1 - - - - alaw - - - - - - - - - - - g726 - - - - - - - - - - - adpcm - - - - - - - - - - - slin - - 1 - - - - - - - - lpc10 - - - - - - - - - - - g729 - - - - - - - - - - - speex - - - - - - - - - - - ilbc - - - - - - - - - - - Any suggestions on hardware? Are you talking the entire server or components? I'll look into the megaraid2 drivers, but I'm interested in knowing how they come into play when recording to a RAM disk. Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer Matt Florell wrote: What codec are the calls? What codec are you recording in? I would try some non-Dell hardware, I would also try a less bloated Linux Distro, something like Slackware, just to see if that had any effect. And make sure you use the megaraid2 linux drivers. MATT--- On 12/13/05, Matt Roth [EMAIL PROTECTED] wrote: Matt Florell wrote: Hello, Need some more information here: - hardware specs (including what kind of hard drives?) The Asterisk server is a Dell PowerEdge 6850 with the following specs. Please note that we are NOT recording to the hard drive. We are recording to a RAM disk as detailed here (http://voip-info.org/wiki/view/Asterisk+Dimensioning) under the heading "512 simultaneous SIP-to-SIP calls with Digital Recording". Unfortunately, the scalability tests we did at that time assumed that if call quality was good, so was the quality of the recording. Processor: Quad Intel Xeon 3.16GHz/1MB Cache Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk) Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored) Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver: megaraid_mm, megaraid_mbox) Everything else: http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf - Linux kernel version 2.6.12-1.1376_FC3smp (Fedora Core 3). - running Xwindows? No. - Asterisk version ABE-A.2-beta (Asterisk Business Edition A.2 beta). - kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) Calls originate on the PSTN and are handled by a Cisco AS5400 Universal Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls from TDM channels to VoIP (SIP) channels before sending them to Asterisk. The Asterisk dialplan then routes them to one of our agents, who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls are SIP-to-SIP, with absolutely no protocol bridging or transcoding occurring on the Asterisk server. The Asterisk server handles the following major tasks: - Routing calls through the dialplan to (dynamic) agents in the appropriate queues. - Adding/removing agents to/from queues via AddQueueMember and RemoveQueueMember (NO static agents!). - Recording calls via the Monitor application directly to RAM disk. Calls are moved to a remote machine for mixing. - ChanSpy-based quality assurance of calls. Neither ChanSpy nor the quality of the calls themselves is affected by the problem. - how many recordings at once Anywhere from 5 to 30 concurrent recordings. This is not our planned peak, but it's where we've experienced the problem so far. We have not yet determined if the number of concurrent recordings is an issue, but we are considering it. We also haven't determined if the problem gets worse as the number of recordings increases, but it definitely exists throughout that entire range. In my experience, HyperThreading does not cause recording problems, it's usually a disk issue. When we had issues, switching to fast SCSI drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all of our problems(skips and clicks/pops) The disk issues also directly interfere with call quality, as our previous scalability tests showed. Digium seems to think that the issue is scaling (some resource contention that causes a bit of audio to be unavailable when the write occurs). I see their point, but given our hardware and the current call volume I'm not completely sold on it. Could it be a configuration issue (file handles, interrupts, etc...)? MATT--- Colin Anderson wrote: Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today, 1482 calls!) of various length on my Netfinity with the onboard IBM RAID controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the other Matt indicated, maybe what is needed here is an intelligent controller to offload some of the chore. No definite
Re: [Asterisk-Users] Skips and Pops in Call Recordings
Hello, To see if it's somehow the recording throughput that's the problem I'd suggest trying recording in GSM just as a test and see how that is. As for the hardware, just try a machine with no Dell parts in it. I've talked to many Asterisk users who's problems went away when they switched to something that wasn't a Dell. MegaRAID2 might help just because it's another reduction in the overall data that flows over the PCI bus. It's faster and more streamlined than the original megaraid driver and it can't hurt to try it. MATT--- On 12/13/05, Matt Roth [EMAIL PROTECTED] wrote: Matt, The calls are u-Law. The format of the recordings is PCM. Is this correct to prevent transcoding the recording? We've noloaded all other codecs, so I don't believe that transcoding is occurring. I've only ever seen show translation generate the following output: immlx15*CLI show translation Translation times between formats (in milliseconds) Source Format (Rows) Destination Format(Columns) g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex ilbc g723 - - - - - - - - - - - gsm - - - - - - - - - - - ulaw - - - - - - 1 - - - - alaw - - - - - - - - - - - g726 - - - - - - - - - - - adpcm - - - - - - - - - - - slin - - 1 - - - - - - - - lpc10 - - - - - - - - - - - g729 - - - - - - - - - - - speex - - - - - - - - - - - ilbc - - - - - - - - - - - Any suggestions on hardware? Are you talking the entire server or components? I'll look into the megaraid2 drivers, but I'm interested in knowing how they come into play when recording to a RAM disk. Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer Matt Florell wrote: What codec are the calls? What codec are you recording in? I would try some non-Dell hardware, I would also try a less bloated Linux Distro, something like Slackware, just to see if that had any effect. And make sure you use the megaraid2 linux drivers. MATT--- On 12/13/05, Matt Roth [EMAIL PROTECTED] wrote: Matt Florell wrote: Hello, Need some more information here: - hardware specs (including what kind of hard drives?) The Asterisk server is a Dell PowerEdge 6850 with the following specs. Please note that we are NOT recording to the hard drive. We are recording to a RAM disk as detailed here (http://voip-info.org/wiki/view/Asterisk+Dimensioning) under the heading 512 simultaneous SIP-to-SIP calls with Digital Recording. Unfortunately, the scalability tests we did at that time assumed that if call quality was good, so was the quality of the recording. Processor: Quad Intel Xeon 3.16GHz/1MB Cache Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk) Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored) Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver: megaraid_mm, megaraid_mbox) Everything else: http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf - Linux kernel version 2.6.12-1.1376_FC3smp (Fedora Core 3). - running Xwindows? No. - Asterisk version ABE-A.2-beta (Asterisk Business Edition A.2 beta). - kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) Calls originate on the PSTN and are handled by a Cisco AS5400 Universal Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls from TDM channels to VoIP (SIP) channels before sending them to Asterisk. The Asterisk dialplan then routes them to one of our agents, who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls are SIP-to-SIP, with absolutely no protocol bridging or transcoding occurring on the Asterisk server. The Asterisk server handles the following major tasks: - Routing calls through the dialplan to (dynamic) agents in the appropriate queues. - Adding/removing agents to/from queues via AddQueueMember and RemoveQueueMember (NO static agents!). - Recording calls via the Monitor application directly to RAM disk. Calls are moved to a remote machine for mixing. - ChanSpy-based quality assurance of calls. Neither ChanSpy nor the quality of the calls themselves is affected by the problem. - how many recordings at once Anywhere from 5 to 30 concurrent recordings. This is not our planned peak, but it's where we've experienced the problem so far. We have not yet determined if the number of concurrent recordings is an issue, but we are
Re: [Asterisk-Users] Skips and Pops in Call Recordings - channel.c Analysis
List users,
I've traced the writing of the leg files to two functions in channel.c:
ast_write()
ast_read()
They both contain similar code, so I'm going to limit my analysis to one
of them. If I'm misunderstanding anything or am flat out wrong, please
don't hesitate to correct me. Your input is what I'm looking for.
Below is a code fragment, with some extraneous stuff removed for brevity
and some comments describing what I believe is happening. Please take a
look at it, paying special attention to the comments I've added.
My understanding is that if the channel is locked, the function will
wait on the ast_mutex_lock() call until it is unlocked. Once it is
unlocked, the function attempts to compensate for any loss of leg file
synchronization by jumping the file pointer forward by some value based
on the number of dropped frames. This puts a gap in the leg file which
manifests itself as a popping sound in the format we are using (PCM),
but which probably sounds a little different in other formats.
My main concern is if this fragment is responsible for writing the frame
to its destination via RTP. If it is, the skips and pops in the
recordings would likely manifest themselves as dropped audio on the
calls. Is this correct? Do problems in the recordings indicate parallel
problems in call quality? The reports from our agents don't seem to
support this, but looking at the code worries me.
Thank you very much,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
=
int ast_write(struct ast_channel *chan, struct ast_frame *fr)
{
/* Lock the channel */
ast_mutex_lock(chan-lock);
/*
... Code Omitted ...
*/
/* Check to see if the channel is blocking */
CHECK_BLOCKING(chan);
/* Switch based on frame type */
switch(fr-frametype) {
/*
... Code Omitted ...
*/
/* Handle voice frames */
default:
/* Validate a function pointer */
if (chan-pvt-write) {
/* Validate another function pointer */
if (chan-pvt-writetrans) {
f = ast_translate(chan-pvt-writetrans, fr, 0);
} else
f = fr;
/* Validate the frame pointer */
if (f) {
/* I'm not sure what this does, so please let me know if
you do.
I really hope that it's not responsible for writing
the frame out to its destination via RTP. */
res = chan-pvt-write(chan, f);
/* If this channel is being monitored write the frame to
the appropriate leg file */
if( chan-monitor
chan-monitor-write_stream
f ( f-frametype == AST_FRAME_VOICE ) ) {
/*
If some frames have been missed, jump the leg file
pointer forward to keep the leg files synchronized.
!!! I BELIEVE THIS IS THE SOURCE OF THE SKIPS AND POPS
IN THE RECORDINGS !!!
*/
#ifndef MONITOR_CONSTANT_DELAY
int jump = chan-insmpl - chan-outsmpl - 2 *
f-samples;
if (jump = 0) {
if (ast_seekstream(chan-monitor-write_stream,
jump + f-samples, SEEK_FORCECUR) == -1)
ast_log(LOG_WARNING, Failed to perform seek
in monitoring write stream, synchronization between the files may be
broken\n);
chan-outsmpl += jump + 2 * f-samples;
} else
chan-outsmpl += f-samples;
#else
int jump = chan-insmpl - chan-outsmpl;
if (jump - MONITOR_DELAY = 0) {
if (ast_seekstream(chan-monitor-write_stream,
jump - f-samples, SEEK_FORCECUR) == -1)
ast_log(LOG_WARNING, Failed to perform seek
in monitoring write stream, synchronization between the files may be
broken\n);
chan-outsmpl += jump;
} else
chan-outsmpl += f-samples;
#endif
/* Write the frame to the leg file */
if (ast_writestream(chan-monitor-write_stream, f) 0)
ast_log(LOG_WARNING, Failed to write data to
channel monitor write stream\n);
}
} else
res = 0;
}
}
/*
... Code Omitted ...
*/
/* Set the channel as not blocking */
chan-blocking = 0;
/*
... Code Omitted ...
*/
/* Unlock the channel and return */
ast_mutex_unlock(chan-lock);
return res;
}
=
___
Re: [Asterisk-Users] Skips and Pops in Call Recordings - channel.c Analysis
Matt,
I have a similar issue to the 'Skips and Pops' with the On Hold
music on my Ast 1.2.1 box. I've tried moving stuff to a RAM Disk, yet I
still get reports from agents that callers report that the 'music on
hold sounds horrible'.
It has squeaks and pops.. kind of like digital satelite distortion..
and looking at what you've said below, it kind of makes sense, since I
can gurantee to re-create the problem by just dragging out a sip phone
and dropping myself in a queue - All MoH sounds terrible, but the Queue
Announcements (Your caller X in the queue) come out perfectly everytime.
The one thing that doesn't sit with your explanation : I seem to
have ZapChannel users complain of the same problem. Im newish to
Asterisk, but I thought RTP only came into play on SIP/IAX/MGCP calls
... So the fact that I seem to have the problem when calling from a CO
Trunk line (well, Inbound PRI) into a digium 4 port PRI card means it
couldn't be RTP related? just frame related?
Adrian
Matt Roth wrote:
List users,
I've traced the writing of the leg files to two functions in channel.c:
ast_write()
ast_read()
They both contain similar code, so I'm going to limit my analysis to
one of them. If I'm misunderstanding anything or am flat out wrong,
please don't hesitate to correct me. Your input is what I'm looking for.
Below is a code fragment, with some extraneous stuff removed for
brevity and some comments describing what I believe is happening.
Please take a look at it, paying special attention to the comments
I've added.
My understanding is that if the channel is locked, the function will
wait on the ast_mutex_lock() call until it is unlocked. Once it is
unlocked, the function attempts to compensate for any loss of leg file
synchronization by jumping the file pointer forward by some value
based on the number of dropped frames. This puts a gap in the leg file
which manifests itself as a popping sound in the format we are using
(PCM), but which probably sounds a little different in other formats.
My main concern is if this fragment is responsible for writing the
frame to its destination via RTP. If it is, the skips and pops in the
recordings would likely manifest themselves as dropped audio on the
calls. Is this correct? Do problems in the recordings indicate
parallel problems in call quality? The reports from our agents don't
seem to support this, but looking at the code worries me.
Thank you very much,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
=
int ast_write(struct ast_channel *chan, struct ast_frame *fr)
{
/* Lock the channel */
ast_mutex_lock(chan-lock);
/*
... Code Omitted ...
*/
/* Check to see if the channel is blocking */
CHECK_BLOCKING(chan);
/* Switch based on frame type */
switch(fr-frametype) {
/*
... Code Omitted ...
*/
/* Handle voice frames */
default:
/* Validate a function pointer */
if (chan-pvt-write) {
/* Validate another function pointer */
if (chan-pvt-writetrans) {
f = ast_translate(chan-pvt-writetrans, fr, 0);
} else
f = fr;
/* Validate the frame pointer */
if (f) {
/* I'm not sure what this does, so please let me know if
you do.
I really hope that it's not responsible for writing
the frame out to its destination via RTP. */
res = chan-pvt-write(chan, f);
/* If this channel is being monitored write the frame
to the appropriate leg file */
if( chan-monitor
chan-monitor-write_stream
f ( f-frametype == AST_FRAME_VOICE ) ) {
/*
If some frames have been missed, jump the leg file
pointer forward to keep the leg files synchronized.
!!! I BELIEVE THIS IS THE SOURCE OF THE SKIPS AND
POPS IN THE RECORDINGS !!!
*/
#ifndef MONITOR_CONSTANT_DELAY
int jump = chan-insmpl - chan-outsmpl - 2 *
f-samples;
if (jump = 0) {
if (ast_seekstream(chan-monitor-write_stream,
jump + f-samples, SEEK_FORCECUR) == -1)
ast_log(LOG_WARNING, Failed to perform
seek in monitoring write stream, synchronization between the files may
be broken\n);
chan-outsmpl += jump + 2 * f-samples;
} else
chan-outsmpl += f-samples;
#else
int jump = chan-insmpl - chan-outsmpl;
if (jump - MONITOR_DELAY = 0) {
if
Re: [Asterisk-Users] Skips and Pops in Call Recordings
Hello, Need some more information here: - hardware specs (including what kind of hard drives?) - Linux kernel version - running Xwindows? - Asterisk version - kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) - how many recordings at once In my experience, HyperThreading does not cause recording problems, it's usually a disk issue. When we had issues, switching to fast SCSI drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all of our problems(skips and clicks/pops) MATT--- On 12/12/05, Matt Roth [EMAIL PROTECTED] wrote: List users, I'm using the Monitor application to record calls. Most of the recordings are audible, but contain skips accompanied by a popping sound. Sometimes they are isolated, sometimes they appear in groups. Call quality is excellent and seems unaffected by whatever is causing this problem. If anyone has experienced this problem before, I'd appreciate if you'd share what the source was and any tips on eliminating it. I contacted Digium tech support and they suggested turning off hyperthreading. I have done that, but I won't know if it improved things until tomorrow. The machine is running at a moderate call volume and is always at least 90% idle. I'm not seeing any Avoided deadlock messages in the logs. If you need any more information, I'd be happy to provide it. Thank you, Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: [Asterisk-Users] Skips and Pops in Call Recordings
I'm using the Monitor application to record calls. Most of the recordings are audible, but contain skips accompanied by a popping sound. Sometimes they are isolated, sometimes they appear in groups. Call quality is excellent and seems unaffected by whatever is causing this problem. Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today, 1482 calls!) of various length on my Netfinity with the onboard IBM RAID controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the other Matt indicated, maybe what is needed here is an intelligent controller to offload some of the chore. No definite solution here, but at least it's another data point to compare. ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
