Asterisk mark2 echo canceller

Echo cancellation in Asterisk — ECHO_CAN_MARK2



Paramters (in mec2_const.h)

DEFAULT_BETA1_I1/(compromise stepsize constant, beta1); higher value means a slower update
DEFAULT_SIGMA_LY_I-log2(filter constant) for reference power estimate; higher value means a slower update
DEFAULT_SIGMA_LU_I-log2(filter constant) for return power estimate; higher value means a slower update
DEFAULT_ALPHA_ST_I-log2(filter constant) for short-term near-end power estimate
DEFAULT_ALPHA_YT_I-log2(filter constant) for short-term reference power estimate
DEFAULT_CUTOFF_IMin. clip for short-term reference power estimate
DEFAULT_HANGThang time after near end-speech to hold coefficients for
DEFAULT_SUPPR_I Ratio of reference/return signal power above which to perform residual echo suppression
MIN_UPDATE_THRESH_IMinumum return power below to do coefficient update, scaled by 1 << DEFAULT_SIGMA_LU_I. Decreasing this will increase cpu usage, without producing much improvement in cancellation
DEFAULT_M frequency of coefficient update, for block-update algorithm
SUPPR_FLOOR not used
SUPPR_CEIL not used
RES_SUPR_FACTOR not used
AGGRESSIVE_HCNTR permissible remaining hangtime under agressive suppressor to do suppression (ie, actual hangtime for suppressor is DEFAULT_HANGT - AGGRESSIVE_HCNTR. (For the normal suppressor, the hangtime is just DEFAULT_HANGT)
AGGRESSIVE_SUPPRESSOR (in zconfig.h) Enable a more agressive residual-echo suppresion algorithm



I was going to write all about how this algorithm works, and some techniques for tuning it. But after spending several days poring over it, I'm still somewhat in the dark. Furthermore, I'm pretty sure some of the maths is flawed - or at least, crippled by inaccurate calculations. It sort of works - but I think that's more by luck than judgement.

I found the following usefull it was posted on http://lists.digium.com/pipermail/asterisk-users/2005-March/093385.html


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


See also


Echo cancellation in Asterisk — ECHO_CAN_MARK2



Paramters (in mec2_const.h)

DEFAULT_BETA1_I1/(compromise stepsize constant, beta1); higher value means a slower update
DEFAULT_SIGMA_LY_I-log2(filter constant) for reference power estimate; higher value means a slower update
DEFAULT_SIGMA_LU_I-log2(filter constant) for return power estimate; higher value means a slower update
DEFAULT_ALPHA_ST_I-log2(filter constant) for short-term near-end power estimate
DEFAULT_ALPHA_YT_I-log2(filter constant) for short-term reference power estimate
DEFAULT_CUTOFF_IMin. clip for short-term reference power estimate
DEFAULT_HANGThang time after near end-speech to hold coefficients for
DEFAULT_SUPPR_I Ratio of reference/return signal power above which to perform residual echo suppression
MIN_UPDATE_THRESH_IMinumum return power below to do coefficient update, scaled by 1 << DEFAULT_SIGMA_LU_I. Decreasing this will increase cpu usage, without producing much improvement in cancellation
DEFAULT_M frequency of coefficient update, for block-update algorithm
SUPPR_FLOOR not used
SUPPR_CEIL not used
RES_SUPR_FACTOR not used
AGGRESSIVE_HCNTR permissible remaining hangtime under agressive suppressor to do suppression (ie, actual hangtime for suppressor is DEFAULT_HANGT - AGGRESSIVE_HCNTR. (For the normal suppressor, the hangtime is just DEFAULT_HANGT)
AGGRESSIVE_SUPPRESSOR (in zconfig.h) Enable a more agressive residual-echo suppresion algorithm



I was going to write all about how this algorithm works, and some techniques for tuning it. But after spending several days poring over it, I'm still somewhat in the dark. Furthermore, I'm pretty sure some of the maths is flawed - or at least, crippled by inaccurate calculations. It sort of works - but I think that's more by luck than judgement.

I found the following usefull it was posted on http://lists.digium.com/pipermail/asterisk-users/2005-March/093385.html


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


See also


Created by: richvdh, Last modification: Wed 27 of Jul, 2005 (01:09 UTC) by SoloFlyer
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+