[Asterisk-Users] Echo problem update - POSSIBLE SOLUTION

[Rich Adamson]

> So are saying that T2240 will gurantee no echo issues? Did you get any
> echo issues with a different PC with the same cards and Pstn lines?
<snip>
>     >>>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?

Nope. the intent of that post was only to suggest that echo resolution
varies by system, and has nothing to do with how fancy/speedy of a 
Compaq/Dell/HP/IBM/<insert-your-favorite-box-here> you might be 
considering or have available, or how much you spent for it. The 
T2240 with tdm-x100p cards in "one US case" does not have echo after
the echotraining=800 implementation. Don't read anything more into it
then just that. (The echotraining=800 was enough of a change for that
exact system implementation to function well. The next one may not.)

Some strong arguments have been made off-list the existing echo 
cancellation function is highly dependent upon interrupt latency,
motherboard chipset in use, PCI controller, and/or other system-level 
items that might even include driver inefficiencies of the NIC card. 
Its way to early to pin the issue any closer, and might even involve
more then one item. (Gary Mart is focusing on this and I'm sure he
would appreciate any technical/programming help he can get. Now I
wish I wouldn't have let those skills go years ago.)

Swapping motherboards can impact echo but doing so does not address
the root cause, only the symptoms. It would be nice to know XXX board
works and YYY board does not, but the professional approach should
focus on the underlying issue(s) and correcting/compensating for those,
if possible. It could be something as simple as a linux installation 
default (eg, assuming 33mhz buss, choice of drivers), or as complex 
as rewriting how the cancellation algorithm functions in general.

It "is" known that a lot of implementations don't have echo, and
apparently those boxes are using internal system resources that fall 
within the tolerances of the existing cancellation routines AND
those boxes have been correctly interfaced to their pstn. Why 
others don't needs to be identified, and unfortunately, is not a
simple task.

In the past eight months we've all listened to suggestions that
include killing the system's GUI interface, don't share interrupts, 
reverse tip & ring, etc, etc. However, it now _appears_ those were
probably addressing the symptom and not the root cause.

It's still most appropriate to ensure the pstn interfacing is 
implemented correctly including source of T1 sync, impedance matching,
adjust gain parameters to reasonable levels, use of proper interface
cards for your country's pstn standards, etc.

Rich