[Asterisk-Users] more cpu intensive echo cancellers ?

Steve Underwood steveu at coppice.org
Sat Feb 11 10:36:00 MST 2006


Matthew Fredrickson wrote:

>
> On Feb 10, 2006, at 10:25 PM, Steve Underwood wrote:
>
>> Matthew Fredrickson wrote:
>>
>>>
>>> On Feb 10, 2006, at 1:21 PM, Gerard Saraber wrote:
>>>
>>>>
>>>> Found it, going to go test it right now :) thanks!
>>>> So far reports have been positive on the echo, but its a slow day ;)
>>>> We're using cisco 7960 phones, they're pricy, but they work great and
>>>> sound good, if it wasn't for the echo issue, I would have been able to
>>>> roll the whole setup out already.
>>>> Actually that's not quite true, I still have to make the 7914 addon
>>>> module work with the 7960 phone, but that's not a show stopper.
>>>>
>>>> Either way, so far big thumbs up for the MG2 echo can, and if any
>>>> developers read this, feel free to add a compile flag to make it more
>>>> cpu intensive ;) and do more canceling.
>>>>
>>>
>>> Does latest MG2 behave better than KB1 on your analog lines?  I 
>>> heard in the past that in some cases (primarily with analog lines) 
>>> that KB1 worked better.  Also, have you tried the echotraining=800  
>>> (in zapata.conf) tweak as well?
>>
>>
>> A lot of the variability is probably due to thr lack of a DC blocker 
>> at the front of the echo canceller. As far as I remember, none of the 
>> cancellers in * has a DC blocker.
>>
>
> Where can one find out more information on writing a DC blocker?  I 
> google'd around a bit, but couldn't find a definitive overview of what 
> one was, and how to write one.  Thanks!
>
DC in the signal through the echo canceller represents a signal the 
canceller's adaption can never eliminate. It fights; it fails; it many 
get very upset trying. DC needs to be eliminated before cancellation. 
A-law/u-law ports are not supposed to give you any DC, but some do. The 
following will estimate and remove DC from the signal. Prime 
"dc_estimate" with zero.

int 16_t dc_removal(int32_t &dc_estimate, int16_t sample)
{
    dc_estimate += ((((int32_t) sample << 15) - dc_bias) >> 9);
    sample -= (dc_estimate >> 15);
    return sample;
}

Its a first order noise shaped single pole IIR. '9' is the damping 
factor. If you make it bigger, the low frequency response will improve, 
but the estimate will take longer to settle after step changes. This may 
affect initial convergence if a DC hiccup occurs as the line is picked 
up. 9 should be a good starting point to try.

Regards,
Steve




More information about the asterisk-users mailing list