[Asterisk-Users] Echo problem update - POSSIBLE SOLUTION

[Steve Underwood]

Rich Adamson wrote:

>>On Fri, 2004-07-16 at 12:07 -0600, Rich Adamson wrote:
>>
>>    
>>
>>>No echo on eMachine T2240 2.2ghz Celery, 360m RAM, with either tdm04b
>>>or x100p running any Head cvs after June 23rd (totally stock install).
>>>
>>>Wouldn't necessarily recommend this box for any commercial production
>>>use, but...
>>>
>>>What's common and not so common between these _very_ diverse boxes?
>>>      
>>>
>>My guess would be interrupt and/or PCI latency. Echo is produced by
>>delays in the audio path so if some motherboards are adding delays it's
>>going to make the echo worse. Fiddling with PCI bus settings both in the
>>BIOS and from Linux (using the pci tools) may help in some cases.
>>
>>The unfortunate part about this is that there are SO many variables that
>>can influence latency that you can't really tell if a motherboard is
>>going to work or not until you try it. Even two MBs with the same CPUs
>>and the same north/south bridges could produce different results.
>>Probably the best we can hope for right now is to start building a
>>whitelist of known good motherboards for people to reference when
>>building Asterisk systems.
>>    
>>
>
>I'm kinda thinking you're right in the ball park of where 'at least some'
>of the remaining echo issues might be coming from. We have an entire
>laundry list of what its _not_, but nothing substantial in terms of
>what _might_ be causing it on selected systems and no good way to
>quantify it.
>  
>
Frame slips could explain some. All the reports of pages getting chopped 
while using the SofFax in spandsp, which I have followed up on, have 
been due to frame slips. It seems a lot of people have their clocking 
wrong, and those slips willscrew the training of an echo canceller just 
as well as they screw up modems.

>Anyone have the knowledge/experience to be able to write "something"
>that might provide all of us with a clue in terms of buss latency
>(or whatever we might want to call this)?
>
>I'm not a programmer, but it would seem like this test app would have to
>run in a manner similar to *, interact with digium cards, and return 
>some value that would represent overall latency. Don't think its all
>that important whether it returns an accurate number of milliseconds
>or some integer value, as long as the value can be compared from one
>motherboard to another (and from one site to another). Sort of a
>"run this and tell me what value is returned" kind of thing.
>  
>
An app that loops back multiple ports and pumps data around in circles 
for hours would shake out a lot of flaky systems. I used to use one in 
the early days of the Tormenta 1 card, but I probably don't have it any 
more.

Regards,
Steve