> I'm not the OP, but I had a similar problem, in my case fxotune ran > successfully for just one out of 3x FXO modules, but the coefficients were > all 0's. My kernel is 2.6.11 on CentOS 4.1. > > So I'm curious if 2.6 kernel (instead of 2.4) has any input in this whole > echo issue, not just fxotune. > > Yesterday I switched to KB1 echo canceller, it is by far the best. But today > I had a similar experience to Eric Rees's Strange Echo post. After > transfering to another internal line, echo starts. My theory is that after > transfer some characteristics of the internal connection change, especially > the Tx voice (the person talking on our side changes). So if the echo > canceller is too committed to the voice of the first person answering the > line (the operator), that would be quite expected. I don't know how KB1 or > other echo cancellers work, but if I'm right, it would be better if echo > canceller readjusted itself after transfer. Sorry if that's plain wrong. Can > somebody comment please? > > I'm really interested in all posts in this thread and others or documents on > echo. > > Btw, thanks Eric Wieling for the Cisco link.
That article is an excellent read. Readers should be a little carefull with it however as there can be additional sources not mentioned in the article. Others that have more capability to read code then I might want to comment on the following to help ensure we're all running with the same reasonable understanding. Relative to asterisk's canceler and based on two years of rather heavy experience with asterisk, one can characterize the existing canceler(s) by saying there are two distinct functional pieces: 1. the pstn line pulsing used to preload the canceler, and, 2. the ongoing real-time training. The first function is controlled by 'echotraining=800' (or whatever value including 'yes' might be provided) in zapatal.conf. The second part can actually be heard in most implementations by changing echotraining=no and listen to an actual call. Typically, it takes about ten seconds or so for the training to occur. (The actual time varies depending upon how good/bad the end-to-end circuit happens to be. Is it practical to 'assume' that in your case mentioned above that #1 is not going to occur again (since I assume when you say 'line' you are referring to an outside pstn line), and, #2 is in a mode of fine-tuning the training when in fact you'd really like it to start the coarse-training from scratch? Relative to the fxotune app, it would appear the app is specific to the v2.4 kernels (/dev/zap*), which the v2.6 kernels don't use (but rather the udev equivalent). (When I had * running on a v2.4 kernel, the output from fxotune never deviated from all zero's. So I'm assuming the default chipset values were already tweaked by the chipset manufacturer to US telco lines. If that is true, then running fxotune in the US has very little value.) The KB1 canceler _does_ work just fine in the v2.6 kernels and I'm in favor of moving it to the default for future Head and Stable releases as soon as practical. _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
