[Asterisk-Users] Tweaking AGGRESSIVE_SUPPRESSOR

[Kris Boutilier]

The style of echo canceller in use in MEC2 cannot cope with both echoed sound and 'new' sounds coming down the pipe at the same time (double talk). Accordingly it has to stop certain parts of the processing during the so called event. Once double talk has been 'detected' the echo can is frozen for at least DEFAULT_HANGT samples (the default is 600 samples = 75ms). Put another way, the echo can stays frozen at least 75ms _after_ the end of detectable double talk - known variously as the 'holdover' or 'hangover' timer. The AGGRESSIVE_HCNTR on the other hand causes the echo can tracking to kick back in _before_ the holdover timer has expired (default 160 samples = 20ms). In addition, enabling the 'aggressive suppression' option also changes the math around subtraction of the echo model from the signal resulting in stronger suppression at the cost of more noticable distortion on low-echo calls.
 
You can find a fairly detailed reference implementation of the same algorithm in:
 
 Messerschmitt, David; Hedberg, David; Cole, Christopher; Haoui, Amine; Winship, Peter; "Digital Voice Echo Canceller with a TMS32020", in Digital Signal Processing Applications with the TMS320 Family, pp. 415-437, Texas Instruments, Inc., 1986.

A pdf of which is available by searching on the quoted document title at http://www.ti.com/

I would suggest experimenting with (raising) the value of MIN_UPDATE_THRESH_I if you're getting unsupressed echo. My understanding is that this represents the minimum reference signal power estimate level that will cause filter adaptation. If this is too low relative to the signals coming off the T1 then background noise can cause the filter coefficients to constantly be updated and the echo can to 'diverge'. 
 
I suspect the problems people have are to do with digital pad being added to the signal somewhere that pushes the signal floor out of range of the fixed constants that this implementation uses - hence people who have success from fiddling with the channel gain parameters. I've got a sneaking suspicion its Central Office related - perhaps some vendors switches correct for pad before putting digital signals out to the customer? We're hooked to a Lucent GTD5 remote office and I've had bad, but extremely inconsistent echo problems with both analog and digital 1B channels regardless of where the far end is - down the road or across the country. I've heard of others doing VoIP on the same model switch with similar problems. 
 
I've put quite a few tens of hours into understanding MEC2 and I'm still nowhere near all the way there. Getting input on this kind of thing from people with the CO engineering experience gets difficult... I'll be honest here - we coughed up for some an old mid 1980s Tellabs 2531 hardware echo cans off of eBay and they did a 100% better job than any of the software cans provided with Asterisk. Wierdly that Tellabs still has issues with some calls (particularly with loud background noise) but upgrading to a newer 2572 64ms unit pretty much took care of that too. Regardless, do not underestimate the damage unresolved echo can do to the viability of a VoIP project.

Hope that helps.
Kris Boutilier
 

-----Original Message-----
From: Dennis Webb [mailto:dwebb at delta-express.cc]
Sent: Monday, March 07, 2005 10:51 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Tweaking AGGRESSIVE_SUPPRESSOR


This seems to be how AGGRESSIVE_SUPPRESSOR works.  To make sure you don't get echo, it does what a speakerphone does, mute the other party if it hears audio from your end.  There is a setting in mec2_const.h for AGGRESSIVE_HCNTR=160 that says in the comments 20ms, I'm assuming this is to tell how long to suppress the other party.  There is nothing on this that I have found anywhere and since we are live, I can't change until later to see how it works. 
 {clip}