<span class="gmail_quote">On 9/21/05, <b class="gmail_sendername">Matt Roth</b> <<a href="mailto:mroth@imminc.com">mroth@imminc.com</a>> wrote:</span><br>
<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- What format are you recording to?<br>- What codec are the SIP calls being placed over?
<br>We are recording to the PCM format and using the G711 uLaw codec. High<br>voice quality is essential to our application (we are a call center) so<br>we partnered with MCI to configure our network for the required<br>
bandwidth and chose the highest quality, zero compression codec. We<br>noload all other codecs in order to avoid transcoding on the switch, so<br>we must record to PCM. Later (on a separate server) the recordings are<br>
mixed to GSM which provides a 5 to 1 compression ratio with very little<br>artifacts.</blockquote><div><br>
Have you tried recording directly to GSM format? It will help reduce
the bottleneck on disk IO although it will use more CPU cycles(in your
case on a RAM drive this may not help at all) <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- We've run into the "Avoided deadlock" recording issues several times<br>
when trying to do<br>- more than 50 concurrent recordings. Changing the ast_channel_lock loop<br>from 10 to 20 has<br>- helped somewhat reduce the warnings and reduce audio gaps on the<br>recordings, but what is<br>- really needed for more robust recording is a configurable recording
<br>buffer that wouldn't<br>- freak out if a 10ms delay occurs.<br>Are you saying that these messages indicate a gap in a digital<br>recording? If so, what is the duration of the gap? If it's comparable<br>to a CD skip, I think we can deal with it until a buffer or another
<br>solution is implemented.</blockquote><br><div>There
aren't always audio skips but they do happen more when you get more
ast_channel_walk warnings. The audio gaps are usually less than a
quarter second in our experience but can be upto a second depending on
the severity of the IO problem at that instance. It's very hard to test
for until you get into production and you have real conversations and
real people listening to them that can hear the audio skips.<br>
<br>
We have sevaral call centers as well, and we just restrict a single
server to 50 recordings at once and then we would pass the next
recording as an IAX2 channel to another recording server. It's a
scalable system for us that is relatively cheap and works well since we
can mix and gsm-encode the audio on these multiple servers at night
when not in production leaving the NSF server just for storage and not
audio processing.<br>
<br>
MATT---<br>
</div><br></div>