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

[Steve Kann]

I'm going to comment to two different issues here:

Ben Kramer wrote:

>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 think in Steve's case, dropping the excess frames is the right thing 
to do.  There's really no way in VoIP to make these things all be 
totally synchronous, because a softphone can't (generally) adjust the 
soundcard's clock..

A softphone basically has two time sources it could choose to 
synchronize the audio it sends to:

1) The computer's system clock
2) The soundcard.

I chose (2) with iaxclient, because it results in the cleanest sound:  
In this way, you send all the audio you get out to the other side, with 
timestamps that make sense w.r.t. the number of samples you're sending, 
etc.  If you try to do (1), then you will end up either needing to 
generate extra samples (using interpolation or silence substitution), or 
drop samples, etc.   If the soundcard's clock was closer to the clock of 
the final destination, this would make things worse.  If not, then the 
final destination can do the same just as easily.

Asterisk doesn't really have a mechanism to be able to synchronize 
channels to each other, and for many channel types, it would be 
infeasible to do so, so channel drivers need to be able to deal with 
it:  maintain a tiny buffer, and if you overflow, drop some audio, and 
if you underflow, play something else (most play silence now, but nicer 
interpolation would improve quality). 


Now, back to Ben's point:

>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.
>  
>
This kinda confuses me:  Is your channel/card trying to cancel the _far 
end echo_?  This sounds like a pretty crazy thing to do, especially 
given that there's no guarantee of synchronicity..  If it's just 
canceling the near-end echo like I'd imagine (i.e. the echo caused by 
the analog device attached to your card), then I'm not sure why delay 
within asterisk would have any effect on that..

-SteveK