> 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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users