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

[tim panton]

On 21 Oct 2005, at 10:44, 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.


I've been working on this sort of problem in my softphone.
The compromise I've evolved (but am still testing) is:

Keep a short buffer (for jitter/packetloss) of 10 samples.
if it fills, drop 5 of them.

This is kinda halfway between the 2 options above.