Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
Asterisk mark2 echo canceller
Echo cancellation in Asterisk — ECHO_CAN_MARK2
- based on code available from Mississippi State Univerisity
Paramters (in mec2_const.h)
|DEFAULT_BETA1_I||1/(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_I||Min. clip for short-term reference power estimate|
|DEFAULT_HANGT||hang 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_I||Minumum 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|
|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.
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+