On Oct 6, 2:59�pm, John McDermick <johnthedsp...@gmail.com> wrote:
> > John
> > I got about 16 dB cancellation with an ordinary NLMS algorithm. What
> > did you get, and what were you expecting?
>
> > Maurice
>
> You're a champ Maurice and really helpful with the feedback :-) Thank
> you!
>
> I got about the same. What's bothering me is that the aec audio output
> is 'smeared'
> during double-talk and I'm not sure which parameters I should be
> tweaking/changing
> to make it sound better. It's the webRTC AEC...in case you want to
> know...
>
> Maybe this smearing effect is just a limitation of AEC's ?? I have
> seen cases where the
> echo gets completely cancelled - even during doubletalk...so I'm
> wondering what it is
> that makes a difference...Is there an implicit limit to how powerful
> the echo can be before
> the near-end speech gets degraded/distorted with loss of
> intelligibility...
What you're hearing is probably a poorly designed double-talk detector
that doesn't stop adaptation before the impulse response estimate is
affected. There is an art to double-talk detection design. Most are
proprietary.
Maurice
Reply by steveu●October 7, 20112011-10-07
>
>>
>> John
>> I got about 16 dB cancellation with an ordinary NLMS algorithm. What
>> did you get, and what were you expecting?
>>
>> Maurice
>
>You're a champ Maurice and really helpful with the feedback :-) Thank
>you!
>
>I got about the same. What's bothering me is that the aec audio output
>is 'smeared'
>during double-talk and I'm not sure which parameters I should be
>tweaking/changing
>to make it sound better. It's the webRTC AEC...in case you want to
>know...
>
>Maybe this smearing effect is just a limitation of AEC's ?? I have
>seen cases where the
>echo gets completely cancelled - even during doubletalk...so I'm
>wondering what it is
>that makes a difference...Is there an implicit limit to how powerful
>the echo can be before
>the near-end speech gets degraded/distorted with loss of
>intelligibility...
The WebRTC AEC is probably the exact thing you need. If you configure it
correctly it has a feature to compensate for the slightly different
sampling rates you get with the mic and speaker channels of a sound card. I
think they actually implemented this to try to echo cancel over a VoIP
link. This is a fruitless task in most cases, as you have little to no
control over what codec translations, jitter buffering and other non-linear
nasties may be going on in the channel. In your case you have just the kind
of signals this AEC was designed for.
I've been trying to find time to test out this canceler for myself, to
solve the exact same problem you seem to be having.
Steve
Reply by John McDermick●October 6, 20112011-10-06
> John
> I got about 16 dB cancellation with an ordinary NLMS algorithm. What
> did you get, and what were you expecting?
>
> Maurice
any chance you could upload your aec output so I can compare and
listen
to how it sounds during double talk?
Thanks
Reply by John McDermick●October 6, 20112011-10-06
>
> John
> I got about 16 dB cancellation with an ordinary NLMS algorithm. What
> did you get, and what were you expecting?
>
> Maurice
You're a champ Maurice and really helpful with the feedback :-) Thank
you!
I got about the same. What's bothering me is that the aec audio output
is 'smeared'
during double-talk and I'm not sure which parameters I should be
tweaking/changing
to make it sound better. It's the webRTC AEC...in case you want to
know...
Maybe this smearing effect is just a limitation of AEC's ?? I have
seen cases where the
echo gets completely cancelled - even during doubletalk...so I'm
wondering what it is
that makes a difference...Is there an implicit limit to how powerful
the echo can be before
the near-end speech gets degraded/distorted with loss of
intelligibility...
Reply by maury●October 6, 20112011-10-06
On Oct 6, 11:32=A0am, John McDermick <johnthedsp...@gmail.com> wrote:
> > Steve
>
> Yes, I remember. So I went on to confirm it by analyzing the signals
> and that's
> what I posted here. I just wanted to have somebody verify that my
> analysis was
> correct.
>
> Anyway, here are the audio files:
>
> http://www.nippyzip.com/uploads/111006113241-33140.zip
John
I got about 16 dB cancellation with an ordinary NLMS algorithm. What
did you get, and what were you expecting?
Maurice
Reply by John McDermick●October 6, 20112011-10-06
>
> Steve
Yes, I remember. So I went on to confirm it by analyzing the signals
and that's
what I posted here. I just wanted to have somebody verify that my
analysis was
correct.
Anyway, here are the audio files:
http://www.nippyzip.com/uploads/111006113241-33140.zip
Reply by steveu●October 6, 20112011-10-06
>Hello,
>
>I have made a script which slides a time-window over the speaker
>signal and the microphone signal. For each window update I save the
>time lag corresponding to the cross correlation peak value. I had
>expected to see a more or less constant lag, but instead I see that it
>is increasing over time.
>
>See chart here:
>
>http://www.nippyzip.com/uploads/111005105627-44838.zip
>
>
>Wouldn't that indicate that the samplerate by which the microphone
>signal is acquired is drifting? If not, what then?
Gee, you have a short memory. I gave you the answer a couple of days ago.
It was an educated guess then. Now its confirmed.
Steve
Reply by maury●October 6, 20112011-10-06
On Oct 5, 9:57=A0am, John McDermick <johnthedsp...@gmail.com> wrote:
> Hello,
>
> I have made a script which slides a time-window over the speaker
> signal and the microphone signal. For each window update I save the
> time lag corresponding to the cross correlation peak value. I had
> expected to see a more or less constant lag, but instead I see that it
> is increasing over time.
>
> See chart here:
>
> http://www.nippyzip.com/uploads/111005105627-44838.zip
>
> Wouldn't that indicate that the samplerate by which the microphone
> signal is acquired is drifting? If not, what then?
John,
What are you using as the test signal? Can you upload your speaker and
microphone files?
Maurice Givens
Reply by John McDermick●October 5, 20112011-10-05
Hello,
I have made a script which slides a time-window over the speaker
signal and the microphone signal. For each window update I save the
time lag corresponding to the cross correlation peak value. I had
expected to see a more or less constant lag, but instead I see that it
is increasing over time.
See chart here:
http://www.nippyzip.com/uploads/111005105627-44838.zip
Wouldn't that indicate that the samplerate by which the microphone
signal is acquired is drifting? If not, what then?