GNOME Bugzilla – Bug 621094
Echo cancellation does not work anymore
Last modified: 2011-08-05 13:42:15 UTC
It stopped working sometimes in the past.
The issue might be related to Opal bug 3085343: http://sourceforge.net/tracker/?func=detail&atid=989748&aid=3085343&group_id=204472
Probably. Please inform us when it is fixed in opal.
One can reproduce this bug in Opal only when a codec with a sampling rate above 8kHz is used. But echo cancellation in Ekiga seems not to work with any codec.
I cannot confirm that echo cancellation does not work at all. I have echo cancelation working on two different machines. Both are running Ubuntu 10.04. I have compiled Ekiga (3.2.7), Opal (3.6.8) and PTlib (2.6.7) myself. On both machines, I am using the microphone input and the speaker output of the sound card as proposed in the Ekiga FAQ (one sound card is recognized as "HDA ATI SB" and one as "HDA NVidia"). I am using the following microphone: http://www.audio-technica.co.jp/products/mic/at9920.html. Echo cancellation only seems to work for certain codecs. I did not try to find out the reason for this. I think echo cancellation is working for the following codecs: iLBC, gsm, G772, Speex, CELT. To subjectively test echo cancellation, I have called either of the two echo canceling machines from an Ekiga installation on Windows and on Ubuntu using a headset. There is a significant audible difference in the echo perceived in the headset if echo cancellation is enabled on the echo canceling machines. Silence detection is not enabled and the jitter buffer is set to 120ms. Of course echo is not canceled 100% and maybe the results are not as intended by the developers, but I perceive a significantly reduced echo. Echo cancellation thus seems to work at least on my two machines described above. It even seems to work best at 8kHz. With the quick fix proposed in the referenced Opal bug, it also seems to work for higher sampling rates. I have tested Speex 16kHz, G772 16kHz, CELT 32kHz and CELT 48kHz.
The Opal bug has been fixed in the Opal trunk (revision 24821)
Yes, it is indeed fixed, thank you!