jrwalliker@gmail.com wrote:
> I'm sorry.  Which bit of your message do you feel I didn't read and
> why?
> 
> I was offering a real example of an ec problem I had recently
> encountered.  Maybe the use of saturation arithmetic wouldn't have
> solved the problem, but surely it might have made the result sound a
> bit less unpleasant.
> 
> John.
> 
I said:

Do things go amiss when there are tones, rather than voice, in the 
channel? Canceller training goes badly astray when the signal is narrowband.

You said:

(This is much easier to identify with
low-frequency test tones - 100Hz is good - where there are many samples
per cycle and it is easy to look at the waveform shape.)

Saturation won't help at all. If there is no adaption, then as you say 
saturation helps a lot. However, overload makes the adaption go crazy, 
and that's true whether you saturate or not. Overload simply wrecks echo 
cancellers. One of the things you need to do in a robust canceller is 
look for overload and freeze the adaption. The canceller you are talking 
about doesn't do that. In fact, it doesn't have any of the bells and 
whistles needed to turn the basic idea of NLMS into a robust solution. 
Without some of those, saturation brings no benefit.

Regards,
Steve

I'm sorry.  Which bit of your message do you feel I didn't read and
why?

I was offering a real example of an ec problem I had recently
encountered.  Maybe the use of saturation arithmetic wouldn't have
solved the problem, but surely it might have made the result sound a
bit less unpleasant.

John.

mobi wrote:
> Hi MMHafezi,
> You can tune the value of meu (make it lower)
> w(k) = w(k) + meu*x*e/norm(x)
> This will effect the convergence speed, which means that the
> coefficients will converge to a solution slow, and in this way
> stability might come, but ofcourse you will be hearing echo till
> convergence. You can implement a more complicated QRD-RLS based echo
> canceller. This will ensure stability and good convergence speed. But
> if you are implementing it for a DSP, it needs lots of computations,
> complexity is roughly in O(N^2) than O(N) for NLMS. You can see the
> QRD-RLS algorithm from Simon Haykins book on adaptive filtering.
> I hope it helps

In my experience with simulated acoustic echo cancellation, NLMS was
very stable.  You could try decreasing mu as mentioned above, which
will slow adaptation.  Also, it's common to use a regularization
parameter - mu*x*e/(x*x+delta).  This will bias your solution a little,
but if it's big enough,  it should keep the algorithm stable.  Start at
your estimate of the noise floor and increase delta from there.  For
example, if the noise is 30dB down from the signal level, start with
delta about 30 dB down.   If you're still having problems, it's
possible you've made an implementation mistake or maybe you're using a
very degenerate signal.

--
-Todd
http://www.signalsguru.net/

jrwalliker@gmail.com wrote:
> I was recently looking at some test recordings that had passed through
> an old version of the Asterisk echo canceller.  With fairly high level
> test tones, an amplified echo came back.  Looking at the echo
> waveforms, I could see the classic appearance of numerical overflow,
> where a large positive number wraps round to a large negative number -
> and the other way round.  (This is much easier to identify with
> low-frequency test tones - 100Hz is good - where there are many samples
> per cycle and it is easy to look at the waveform shape.)
> 
> Clearly there was some point in the ec code where numerical overflow
> was not being saturated properly.  The system recovered by resetting
> the the ec after a short time, but the sound quality was not exactly
> enhanced.

Saturation won't help much. Even if the signal is properly saturated the 
adaption of the canceller will still blow up.

You've replied to a message of mine, but it seems you didn't read it.

Steve

I was recently looking at some test recordings that had passed through
an old version of the Asterisk echo canceller.  With fairly high level
test tones, an amplified echo came back.  Looking at the echo
waveforms, I could see the classic appearance of numerical overflow,
where a large positive number wraps round to a large negative number -
and the other way round.  (This is much easier to identify with
low-frequency test tones - 100Hz is good - where there are many samples
per cycle and it is easy to look at the waveform shape.)

Clearly there was some point in the ec code where numerical overflow
was not being saturated properly.  The system recovered by resetting
the the ec after a short time, but the sound quality was not exactly
enhanced.

John

MMHafezi wrote:
> Hi every body,
> 
> I have implemented a line echo canceller based on NLMS algorithm (TI app.
> note SPRA129) but sometimes the coeficient updatation falls into a bad
> state and echo will amplify. I changed the algorithm in a way that when I
> find this situation has happend I reset the coeficients to zero so it
> takes time again for the coeficients to converge and during this time you
> will hear echo. Because this situtation happens frequently during a call,
> it degrades the quality of canceller very much. 
> 
> Does anybody have any solution for this problem? 

App notes don't usually provide production grade solutions. Look at them 
more as a broad outline of an idea that may or may not be viable. If 
they contain a description and some code, the two seldom agree. Sad, but 
true.

You don't give much idea about what where things go wrong, and there are 
a number of possibilities. For example, so things do astray during 
initial training, or after the training has already stabilised? Do 
things go amiss when there are tones, rather than voice, in the channel? 
Canceller training goes badly astray when the signal is narrowband.

G.168 is the ITU spec for testing acoustic line echo cancellers. It has 
about 15 tests, some of which have several sections. I doubt the 
canceller in SPRA129 would pass more than one or two of those tests. 
Building a basic NLMS canceller is easy. Making it robust is quite 
another matter.

Steve

Hi MMHafezi,
You can tune the value of meu (make it lower)
w(k) = w(k) + meu*x*e/norm(x)
This will effect the convergence speed, which means that the
coefficients will converge to a solution slow, and in this way
stability might come, but ofcourse you will be hearing echo till
convergence. You can implement a more complicated QRD-RLS based echo
canceller. This will ensure stability and good convergence speed. But
if you are implementing it for a DSP, it needs lots of computations,
complexity is roughly in O(N^2) than O(N) for NLMS. You can see the
QRD-RLS algorithm from Simon Haykins book on adaptive filtering.
I hope it helps

Ya MMHafezi,

What did you expect?  That you'll just copy some demo made for marketing 
and that it'll work in real life?  Where have you studied DSP?

If you want a real Echo Canceler that works, then you may refer to 
Compandent's EchoKiller:
http://www.Compandent.com/products_echokiller.htm


> Hi every body,
> 
> I have implemented a line echo canceller based on NLMS algorithm (TI app.
> note SPRA129) but sometimes the coeficient updatation falls into a bad
> state and echo will amplify. I changed the algorithm in a way that when I
> find this situation has happend I reset the coeficients to zero so it
> takes time again for the coeficients to converge and during this time you
> will hear echo. Because this situtation happens frequently during a call,
> it degrades the quality of canceller very much. 
> 
> Does anybody have any solution for this problem? 
>

Hi every body,

I have implemented a line echo canceller based on NLMS algorithm (TI app.
note SPRA129) but sometimes the coeficient updatation falls into a bad
state and echo will amplify. I changed the algorithm in a way that when I
find this situation has happend I reset the coeficients to zero so it
takes time again for the coeficients to converge and during this time you
will hear echo. Because this situtation happens frequently during a call,
it degrades the quality of canceller very much. 

Does anybody have any solution for this problem?