[Asterisk-Dev] echo, delay and dropped packets in channel driver
Ben Kramer
ben at voicetronix.com.au
Thu Nov 3 16:03:22 MST 2005
On Thu, 2005-11-03 at 08:04 +0200, steve at daviesfam.org wrote:
>
> 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?
The echo cancellation breaks due to the huge delay introduced. The issue
is not related to SIP, as the same problem occurs when bridging vpb to
vpb using the ast bridge functions. Basically it is the interaction of
the ast bridge and chan_vpb.c, which is what I am trying to work out.
Cheers,
Ben.
>
> Regards,
> Steve Davies
> Connection Telecom
>
> _______________________________________________
> 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
>
More information about the asterisk-dev
mailing list