[Asterisk-Dev] High resolution timers using POSIX clocks instead of zaptel

[Steven]

On Tue, 2005-06-07 at 14:45 -0400, Steve Kann wrote:
> Steven wrote:
> 
> >On Tue, 2005-06-07 at 13:54 -0400, Steve Kann wrote:
> >  
> >
> >>If things are designed well, and you have 100ms of buffering ability on 
> >>inputs, you can do everything you need to with a 100ms timer;  Just 
> >>process whatever is there at the time.
> >>
> >>For example, if you have generators generating audio to be sent via 
> >>VoIP, then you just do it like this:
> >>
> >>time 0: send nothing.
> >>time 100, send frames 0, 20, 40, 60, 80.
> >>time 200, send frames 100, 120, 140, 160, 180
> >>...
> >>
> >>Same thing for conferencing, etc.
> >>
> >>There's some more latency involved in using a longer timer length, but 
> >>there's also a lot more efficiency, not just from reducing context 
> >>switches, but also from cache locality, etc.
> >>    
> >>
> >
> >Ewww, echo. 100ms of input buffer and up to 20-200ms of transmit time
> >and you have a pretty nasty time of cleaning up that echo. How deep do
> >you think your echo canceler needs to look to clean up the call?
> >
> >That is a great step backwards for those not on VoIP.
> >
> >I doubt any efficiency you gain by consolidating your work would be more
> >than the extra created echo canceler work load.
> >  
> >
> The zaptel ec happens in the kernel driver.  It's totally separate and 
> unrelated to "timers" in asterisk..

It isn't unrelated when you deal with the problems related to the added
delay. I'll point you to all the zaptel to VoIP echo problems people
deal with because of the added delay of just packetization.

> And, while I use 100ms as a strawman here, I would really advocate 
> running most of these timer-related things every 20-40ms or so.

So a timer running every 20ms or so and then the 20ms from the SIP
device before it packetized the audio plus 20-200ms of transit time
means a good chance of quarter second or more of lag before the echo
starts to come back. Do you think the kernel ec will handle a half
second delayed echo without having trouble?

I don't think long timers are a good idea. VoIP users will get a long
enough delay without adding longer timers into it.

Take a VoIP to VoIP conference. 20ms to first packetize, if you use a
20ms timer to mix, you may be up to 40ms from start till you mix and
transmit. Okay, now it gets to the otherside and causes echo and is sent
back 20ms later and mixed up to 40ms later yet. Now we are getting the
echo locally around 80ms late as it is. 

I'd get highly annoyed with that. It would be plenty far enough behind
to be distracting.  
-- 
Steven <critch at basesys.com>