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

[Steve Underwood]

Steven wrote:

>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.
>  
>
Completely irrelevant. Point me to a complaint about echo where 10ms 
timer resolution would make any difference.

>>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?
>  
>
The kernel echo canceller does not and cannot remove echo over the IP 
path. You misunderstand how things work. The EC is to stop echo ever 
getting into the IP link.

>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. 
>  
>
With all the delays through a VoIP link, you would never notice the 
effects of a 10ms timer. Do you think the software magically responds in 
no time at all? Even with a 1ms resolution timer the delays you incur 
will still be significant.

Regards,
Steve