[asterisk-dev] Tuning Software Echo Cancellers

[Rich Adamson]

Andrew Kohlsmith wrote:
> On Sunday 06 August 2006 22:36, Rich Adamson wrote:
>> The echotraining parameter was originally created for analog pstn lines,
>> adding a delay (in the above example, 800 milliseconds) to allow analog
>> central office equipment to settle down before the s/w echo can routines
>> pulsed the line. The reflective energy from the pulse was then used to
>> preload the echo can routines.  Doubtful this parameter should be
>> anything other then =yes on a PRI.
> 
> I was under the impression that echo training in zaptel was used at the 
> beginning of a call to help the echo cancellers train more quickly by muting 
> audio from Asterisk, sending an impulse down the line and measuring the 
> response before unmuting audio and allowing the parties to speak.  Having a 
> known and simple impulse helps the echo canceller train more quickly, which 
> has the effect of reducing the length of time needed to converge.

That's my understanding as well. However, echotraining=800 means "wait" 
for 800 milliseconds before doing the above (allowing time for the 
analog line & CO equipment to settle down after going off-hook). Mark 
and I actually implemented that feature back in the x100p days as a 
result of my echo training issues with Alltel facilities. Since the OP 
is using a PRI, I wouldn't think that parameter has any usefulness given 
digital facilities are not typically subjected to the same 
off-hook-startup issues as analog lines have.

In fact, I'd have to wonder what the status of a PRI call is 800 
milliseconds after initialing a PRI call (from an echo training 
perspective), and, what are we truly training against from the audio 
path perspective.

>> The rxgain and txgain values need only be expressed in units; the
>> numbers after the decimal point have no practical value.
> 
> Again, I thought that integer values were interpreted as percentages, while 
> real numbers were interpreted as decibel values?  Has this changed?  The code 
> seems to indicate that it does indeed accept and use decimal values, but that 
> the use of percentages in gain setting is no longer available.

I'm not positive on this, but I seem to remember that percentage values 
were never acceptable; someone jumped to that conclusion when 
documentation was rather thin on the topic. A percentage number doesn't 
make any sense from a pure transmission engineering / measurement 
perspective.

The point of that (initially) was the OP was tweaking gain values using 
the hundredth of a db, and he's looking for improvements that really 
belong in the units digit (of gain). The intent was to make changes such 
as 1.0, 2.0, or whatever value as opposed to 1.21, 1.22, etc.