<div>I dont know the Sirrix board but if it can be run it in a master/network mode, where the board provides the clock, and you can control the clock divisor with reasonable granularity, then you can code a jitter buffer with a soft PLL to avoid the overrun/underrun due to clock mismatch.
</div>
<div> </div>
<div>Use the arriving data rate on the packet voice side (RTP) to dynamically adjust the output clock on the Sirrix board. This will kill modems/faxs so it needs to be disabled if you detect one or in ISDN data mode.</div>
<div> </div>
<div>Mark <br><br> </div>
<div><span class="gmail_quote">On 10/21/05, <b class="gmail_sendername"><a href="mailto:steve@daviesfam.org">steve@daviesfam.org</a></b> <<a href="mailto:steve@daviesfam.org">steve@daviesfam.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Hi,<br><br>I'm working on a bug with ever-increasing delay seen on a 3rd-party<br>channel driver for Asterisk. (For the Sirrix basic-rate board).
<br><br>This happens when a SIP channel is bridged to this channel driver.<br><br><br>The problem turns out to be that the SIP soft phone is sending audio<br>slightly faster than it leaves through the problem channel driver - about
<br>2% too fast.<br><br>So the audio gradually accumulates in the buffers within the Sirrix<br>device's device driver. And it had way too much buffering.<br><br>I've reduced that buffering.<br><br>But still, I have the problem that sooner or later, whatever size you use,
<br>the write buffer to the device will get full.<br><br>Then what?<br><br>The options I can think of:<br><br>1) When the write fails because the buffer is full, just toss that frame<br>only away.<br><br>The trouble with this is that the device driver buffer fills up and then
<br>stays nearly full. If we are writing 20msec of audio at a time, we'll<br>eventually settle in a pattern of regular and quite frequent glitches in<br>the sent audio. In this case, 20msec of audio is dropped every second or
<br>so, creating quite a nasty effect.<br><br>Plus, latency gets "stuck" at whatever buffer size the device driver is<br>using.<br><br>or,<br><br>2) When the write fails because of full buffer, tell the device driver to
<br>flush the *entire* write buffer<br><br>We make one big, obvious audio drop every now and then - in this case<br>every 26 seconds a "chunk" of 500msec of audio will be dropped.<br><br>or,<br><br>3) "Resample" the audio
<br><br>I guess this is the best approach - to use a resampling process to reclock<br>the audio. This will keep the two sides nicely in step with a 1 byte slip<br>every 50 bytes in my example.<br><br>Is there such a resampler in the code anywhere?
<br><br>What happens in other cases like this (eg SIP -> Zap)<br><br>Thanks and regards,<br>Steve Davies<br><br>_______________________________________________<br>Asterisk-Dev mailing list<br><a href="mailto:Asterisk-Dev@lists.digium.com">
Asterisk-Dev@lists.digium.com</a><br><a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br>