<DIV>Thanks for that. </DIV>
<DIV>Like many I believe * is unusable in production until these echo issues are quoshed are resolved. Lets hope someone takes up the bounty offer.<BR><BR><B><I>Rich Adamson <radamson@routers.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">> So are saying that T2240 will gurantee no echo issues? Did you get any<BR>> echo issues with a different PC with the same cards and Pstn lines?<BR><SNIP><BR>> >>>No echo on eMachine T2240 2.2ghz Celery, 360m RAM, with either tdm04b<BR>> >>>or x100p running any Head cvs after June 23rd (totally stock install).<BR>> >>><BR>> >>>Wouldn't necessarily recommend this box for any commercial production<BR>> >>>use, but...<BR>> >>><BR>> >>>What's common and not so common between these _very_ diverse boxes?<BR><BR>Nope. the intent of that post was only to suggest that echo resolution<BR>varies by system, and has nothing to do with how fancy/speedy of a <BR>Compaq/Dell/HP/IBM/<INSERT-YOUR-FAVORITE-BOX-HERE> you might be <BR>considering or have available, or how much you spent for it. The <BR>T2240 with
tdm-x100p cards in "one US case" does not have echo after<BR>the echotraining=800 implementation. Don't read anything more into it<BR>then just that. (The echotraining=800 was enough of a change for that<BR>exact system implementation to function well. The next one may not.)<BR><BR>Some strong arguments have been made off-list the existing echo <BR>cancellation function is highly dependent upon interrupt latency,<BR>motherboard chipset in use, PCI controller, and/or other system-level <BR>items that might even include driver inefficiencies of the NIC card. <BR>Its way to early to pin the issue any closer, and might even involve<BR>more then one item. (Gary Mart is focusing on this and I'm sure he<BR>would appreciate any technical/programming help he can get. Now I<BR>wish I wouldn't have let those skills go years ago.)<BR><BR>Swapping motherboards can impact echo but doing so does not address<BR>the root cause, only the symptoms. It would be nice to know XXX board<BR>works and YYY
board does not, but the professional approach should<BR>focus on the underlying issue(s) and correcting/compensating for those,<BR>if possible. It could be something as simple as a linux installation <BR>default (eg, assuming 33mhz buss, choice of drivers), or as complex <BR>as rewriting how the cancellation algorithm functions in general.<BR><BR>It "is" known that a lot of implementations don't have echo, and<BR>apparently those boxes are using internal system resources that fall <BR>within the tolerances of the existing cancellation routines AND<BR>those boxes have been correctly interfaced to their pstn. Why <BR>others don't needs to be identified, and unfortunately, is not a<BR>simple task.<BR><BR>In the past eight months we've all listened to suggestions that<BR>include killing the system's GUI interface, don't share interrupts, <BR>reverse tip & ring, etc, etc. However, it now _appears_ those were<BR>probably addressing the symptom and not the root cause.<BR><BR>It's still
most appropriate to ensure the pstn interfacing is <BR>implemented correctly including source of T1 sync, impedance matching,<BR>adjust gain parameters to reasonable levels, use of proper interface<BR>cards for your country's pstn standards, etc.<BR><BR>Rich<BR><BR><BR><BR>_______________________________________________<BR>Asterisk-Users mailing list<BR>Asterisk-Users@lists.digium.com<BR>http://lists.digium.com/mailman/listinfo/asterisk-users<BR>To UNSUBSCRIBE or update options visit:<BR>http://lists.digium.com/mailman/listinfo/asterisk-users<BR></BLOCKQUOTE><p>
<hr size=1> <font size="2" face="Verdana, Arial, Helvetica, sans-serif"><a href="http://uk.rd.yahoo.com/evt=21626/*http://uk.messenger.yahoo.com"><strong>ALL-NEW
Yahoo! Messenger</strong></a><strong> - <font color="#FF9900"><em>sooooo many
all-new ways to express yourself</em></font></strong></font>