asterisk users - Oct 2003 - Echo observations and some questions

I have been doing some research on echoes and echo cancellation.  Here 
is a summary of what I've learned:

    1) When solving echo problems it is extremely important to locate 
the source of the echo, and if possible, eliminate it at the source.  
The most common cause of echo is an unbalanced hybrid at the PSTN to TDM 
interface.  This is where the 2-wire POTS line is divided into a 4-wire 
line (transmit and receive pairs). Under ideal conditions, the hybrid 
subtracts exactly the correct prorportion of the transmitted signal from 
the receive signal path to remove the echo caused by local loopback of 
the transmitted signal.  Imbalance may be from poor design (common) or 
unpredictable impedance conditions on the POTS line (very common).  The 
nature of this kind of echo is that only the near end hears it.  The far 
end is not in the echo loop. In almost all cases, the end user is not 
given any provision for properly balancing the hybrid and is stuck with 
mathematically removing the resulting echo after the fact.

    2) Almost all (if not all) echo cancelling algorithims operate by 
generating multiple copies of the received signal, each delayed by some 
small time increment  In digital terms, this is the equivalent of a 
shift register and each delayed signal appears at its own unique
"tap".
The number of taps determines the size of the echo delay that can be 
cancelled. These delayed copies are then scaled (or weighted) and 
subtracted from the original received signal.  The trick is scaling the 
the delayed signals to exactly the extent needed to remove the echo and 
nothing else.  The methods used in determining the tap weights (scaling 
factors) is what distinguishes one algorithm from another.

    3) The echo canceller must "train" itself by computing the weights
when it first sees a signal at the input.  The training time depends 
upon the algorithm used and the number of taps.  For optimal training, 
the number of taps should be as small as possible, while still 
adequately cancelling the echo.  For the typical scenario being 
experienced by most of us, the signal delay should be relatively short.  
Don't let your ears be the guide here!  The echo you hear has a lot of 
additional delay added between the location of the echo canceller and 
your phone.  The real delay you are interested in is the delay from the 
line card, through the interface and into the * box, terminating at the 
input buffer of the echo canceller.  This delay is relatively short, 
probably less than 20-30 ms.  The take home is that you may get better 
performance with fewer taps because the training time is shorter and the 
canceller will adapt faster. Simply setting echocancel=y defaults to 128 
taps.  I don't know if this is optimal.  I don't even know how many 
milliseconds this many taps represents. Since one of the things that 
seems to be algorithm dependent is the number of ms/tap, I hesitate even 
to guess.  Given this, it is really hard to use a rational approach to 
adjustment, since the ms/tap is not given for any of the cancellers in 
asterisk.  In fact, when reading the code, it isn't clear whether the 
number of taps can even be adjusted for all of the cancellers.  This 
really needs to be specified clearly, at least in the source code.

    4) Algorithmic echo cancellers will never give performance equal to 
that obtained by balancing the hybrid.  This is due to several reasons, 
not the least of which is that the expansion/compaction must be undone 
before cancellation, introducing noise and decreasing accuracy of 
cancellation, and that the delay characteristics and amplitude 
characteristics of the echo are never as well defined as they are at the 
point of origin of the echo (the hybrid).  This is really too bad, since 
we don't get to do anything about the hybrid imbalance.

    5) Only one of the echo cancellers in * identifies itself (Mark's 
original canceller is Simple LMS with Doubletalk detection#), and then, 
the ID is only obtained by reading the source code.  While I suspect 
that I could decipher the algorithms used in the other cancellers if I 
were to spend several weeks studying the problem, the authors already 
know the answer to this and should clue us in, even if only with 
comments in the source files.  The rest - mark2, mark3, steve2, steve3 - 
have no identification of the algorithm at all.  This should be fixed 
right away, since proper selection of an echo canceller is dependent 
upon knowing the algorithm.  You need to know what the training 
performance, tail length, wighting mechanism, etc. If they were 
identified, at least one could consult the literature for information 
about the conditions for which the algorithm is ideal:  is it best for 
room echo associated with speaker phones, is it best for cancelling echo 
from hybrid imbalance, etc

# Doubletalk is the problem the echocanceller encounters when someone at 
the far end (them) is talking at the same time as the speaker at the 
near end (you).

    6) The function of the DAGGRESSIVE_SUPPRESSION switch with MARK2 
should be specified.  While I found the few lines in the source that 
detail the difference, untwisting the algorithmic details embedded in 
these few lines of code is far too difficult, especially when the author 
already knows the answer.  In one of my trials, activating this switch 
made echo cancellation far worse.  I had to turn it back off to get any 
kind of performance at all.

Well, that's my 2 cents worth.  I hope it helps somebody with their echo 
problems.

Stephen R. Besch