[Asterisk-Dev] Any standard "recipe" for dealing with channel datarate mismatches?

[Mark Aiken]

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.
 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.
 Mark

 On 10/21/05, steve at daviesfam.org <steve at daviesfam.org> wrote:
>
>
> Hi,
>
> I'm working on a bug with ever-increasing delay seen on a 3rd-party
> channel driver for Asterisk. (For the Sirrix basic-rate board).
>
> This happens when a SIP channel is bridged to this channel driver.
>
>
> The problem turns out to be that the SIP soft phone is sending audio
> slightly faster than it leaves through the problem channel driver - about
> 2% too fast.
>
> So the audio gradually accumulates in the buffers within the Sirrix
> device's device driver. And it had way too much buffering.
>
> I've reduced that buffering.
>
> But still, I have the problem that sooner or later, whatever size you use,
> the write buffer to the device will get full.
>
> Then what?
>
> The options I can think of:
>
> 1) When the write fails because the buffer is full, just toss that frame
> only away.
>
> The trouble with this is that the device driver buffer fills up and then
> stays nearly full. If we are writing 20msec of audio at a time, we'll
> eventually settle in a pattern of regular and quite frequent glitches in
> the sent audio. In this case, 20msec of audio is dropped every second or
> so, creating quite a nasty effect.
>
> Plus, latency gets "stuck" at whatever buffer size the device driver is
> using.
>
> or,
>
> 2) When the write fails because of full buffer, tell the device driver to
> flush the *entire* write buffer
>
> We make one big, obvious audio drop every now and then - in this case
> every 26 seconds a "chunk" of 500msec of audio will be dropped.
>
> or,
>
> 3) "Resample" the audio
>
> I guess this is the best approach - to use a resampling process to reclock
> the audio. This will keep the two sides nicely in step with a 1 byte slip
> every 50 bytes in my example.
>
> Is there such a resampler in the code anywhere?
>
> What happens in other cases like this (eg SIP -> Zap)
>
> Thanks and regards,
> Steve Davies
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20051022/1ba6c58f/attachment.htm