[Asterisk-Dev] echo, delay and dropped packets in channel driver

[steve at daviesfam.org]

On Thu, 3 Nov 2005, Ben Kramer wrote:

> Im the maintainer of the VoiceTronix channel driver (chan_vpb.c), and am
> trying to track down an issue involving the issue in the subject.
> A customer reported a 160ms delayed echo, which I can reproduce, when
> bridging via ast_bridge. This is when a vpb channel is bridge to any
> other channel via ast_bridge, including SIP and VPB, a native vpb/vpb
> bridge doesn't have this problem.
> I have been trying to track down where the delay is being introduced.
> Here are a few things I have noticed:
> 1) the average time between receiving frames to write out to the board
> is 19ms, often dropping to 18 or 17ms. It is rarely 20ms or more, even
> though the we are being sent 20ms frames.
> 2) I enabled logging in ast_generic_bridge to see the servicing of the
> channels, and I often see one channel or the other being serviced twice
> in a row.
> 
> A decided to try and record the echo being heard, so added a Monitor()
> command to the demo extens. What I see in the record files is no echo,
> but I often see 20/40/60/80 ms gaps of silence in both the in and out
> files.
> 
> Can anybody give me any ideas, comments, or pointers where to go from
> here ?

Hi Ben,

Perhaps some recent experience of mine will be useful.

We had a client using Xten's Eyebeam softphone with the Sirrix basic-rate 
board.  They were getting an ever increasing call-delay rising to a 
ridiculous length.

In the end I found that the Eyebeam softphone was sending more data than 
it should - I guess the PC clock was out.  It seemed to realise that there 
was a problem, and attempted a correction, but due, I presume, to a bug 
it seems to correct backwards and make the situation even worse.

So the nett effect is that in any time period Asterisk receives more than 
8000*seconds worth of audio samples.

Asterisk is just the "slave" of the incoming SIP frames.  So as it 
receives them it sends them out to the outgoing channel.

Now the sirrix is externally synced to the ISDN line so can only send out 
audio at the rate clocked by the line.

So the excess samples accumulated in a buffer in the sirrix kernel driver.
Worse, when the buffer filled, the channel driver actually waited for the 
write - which then caused trouble for other things as the thread got 
blocked.

I reduced that buffer size dramatically and discarded data when the buffer 
filled, which proved an acceptable fix in the face of a broken SIP client.

Unfortunately Xten don't seem to be interested in responding to my offers 
to work with them for a fix.

I don't know whether you could be facing a similar problem.  Perhaps your 
echo can breaks because of buffering delay also in your kernel driver?

Regards,
Steve Davies
Connection Telecom