>
> The audio was recorded from the speaker and mic channels of a PC sound
> card. The DAC sampling rate is slightly different from the ADC sampling
> rate. The gradual sliding of the signals with respect to each other means
> the canceler never converges.
>
> Not all sound cards do this, but it is very common. The ADC is locked to
> the SP/DIF input, which is slaved to whatever drives the SP/DIF input. If
> there is no SP/DIF signal the ADC rate free runs. There may or may not
> actually be a SP/DIF connector on the machine. The DAC rate, meanwhile,
> comes from a local crystal. The two rates are not locked, though they
> remain fairly close to each other. This is hugely annoying for a lot of PC
> audio applications, but that's just how it is and you have to live with
> it.
>
Is this something I can verify somehow by analyzing the actual
signals???
If so, how?
I haven't looked at your audio, but let me guess, as this is a recurring
issue with EC on PCs......
The audio was recorded from the speaker and mic channels of a PC sound
card. The DAC sampling rate is slightly different from the ADC sampling
rate. The gradual sliding of the signals with respect to each other means
the canceler never converges.
Not all sound cards do this, but it is very common. The ADC is locked to
the SP/DIF input, which is slaved to whatever drives the SP/DIF input. If
there is no SP/DIF signal the ADC rate free runs. There may or may not
actually be a SP/DIF connector on the machine. The DAC rate, meanwhile,
comes from a local crystal. The two rates are not locked, though they
remain fairly close to each other. This is hugely annoying for a lot of PC
audio applications, but that's just how it is and you have to live with
it.
Steve
Reply by John McDermick●October 4, 20112011-10-04
>
> You must have recorded these files using a computer soundcard and
> software. Did you record the speaker/microphone signals as a stereo
> pair? If not, is it possible that the speaker recoding is delayed
> relative to the microphone recording, which would make the system anti-
> causal? Also, be aware that some PC soundcard recording software uses
> sample-rate conversion without informing you, so if you recorded the
> speaker and microphone signals at different times you might have some
> alignment issues that can't be solved by simple shifts.
>
> If none of these is the cause, it's possible your speaker has too much
> distortion.
I didn't record the signals. But I am working on getting some
information
about how the signals were recorded.
What do you mean by recording the mic/speaker signal as a stereo pair?
When I import the speaker recording and microphone recording into
audacity, it is obvious that the microphone signal is a little bit
delayed
in relation to the speaker signal. So that's not a problem as far as I
can
tell.
What do you mean by the microphone signal being recorded at a
different
time than the speaker signal? The mic signal will always be recorded
at a
different time than the speaker signal, right?
When the loudspeaker plays out the speaker signal, it takes some
milliseconds before the acoustic audio
captured by the microphone actually shows up in the microphone buffer.
I'm not sure I understand your last comment.
If I had to generate some real signals I would:
1) Acquire a far-end signal at Fs Hz. Convert it to mono if needed.
2) Play out far-end signal through some loudspeakers
3) Have a near-end signal source close to a microphone. Let the near-
end signal source interrupt a little bit while the far-end signal is
being played out.
4) Save the audio samples captured by the microphone
5) If needed: downsample the captured audio to Fs Hz.
6) If needed: convert the downsampled audio to mono.
Anything wrong with the above-mentioned step 1 through 6 ?
And thank you for posting a response :-)
Reply by John McDermick●October 4, 20112011-10-04
> Hi, John! I spent some time experimenting with your code.
> It looks like this particular adaptive filter is unable to adapt to this
> particular path between loudspeaker and microphone.
Sorry for getting back to you this late. I just saw your answer.
I see the same as you. The AEC won't adapt with these particular
test signals.
> Unfortunately I don't know why it is so.
> But when I process "testSpk" signal with FIR filter, which models Room
> Impulse Response, and then use this processed signal as microphone signal,
> then everything works just fine and this modeled echo signal fades quite
> fast.
I have done the same with the same result (that's what I meant by
"other signals").
> Did you record these signals yourself?
No
>How many loudspeakers were in the
> loudspeaker-mic path?
I can find out and get back to you with an answer.
> And what do you mean by "other audio signals I have tested with"?
See above.
> Can you upload these "normal" signals too?
It's basically the same as you did. FIR filter speaker signal using a
simulated room impulse response
to obtain mic signal. In that case the AEC works fine, so I am
wondering what's so "special" about
the actual mic signal that makes the AEC not adapt.
> Were these other signals recorded using same mic, room and loudpeaker(s)?
I don't know, but I can find out.
> Anyway, if you will find out why AEC doesn't work in this case, please post
> answer here.
I will
Reply by Robert Adams●September 27, 20112011-09-27
On Sep 27, 6:04�pm, "alexpazh" <alpazh@n_o_s_p_a_m.gmail.com> wrote:
> >My question should have been posed in a different way. What I meant to
> >ask was if somebody could try and listen to the audio files and
> >suggest why the AEC doesn't work for these particular audio files.
> >There is nothing to debug in the code as it has been compiled (into
> >MEX or what ever it's called). The algorithm works fine for other
> >audio signals I have tested with, but for this particular set of
> >signals it doesn't work...So I'm wondering what it is about these
> >audio files that seperate them from others.
>
> Hi, John! I spent some time experimenting with your code.
> It looks like this particular adaptive filter is unable to adapt to this
> particular path between loudspeaker and microphone.
> Unfortunately I don't know why it is so.
> But when I process "testSpk" signal with FIR filter, which models Room
> Impulse Response, and then use this processed signal as microphone signal,
> then everything works just fine and this modeled echo signal fades quite
> fast.
> Did you record these signals yourself? How many loudspeakers were in the
> loudspeaker-mic path?
> And what do you mean by "other audio signals I have tested with"?
> Can you upload these "normal" signals too?
> Were these other signals recorded using same mic, room and loudpeaker(s)?
>
> Anyway, if you will find out why AEC doesn't work in this case, please post
> answer here.
You must have recorded these files using a computer soundcard and
software. Did you record the speaker/microphone signals as a stereo
pair? If not, is it possible that the speaker recoding is delayed
relative to the microphone recording, which would make the system anti-
causal? Also, be aware that some PC soundcard recording software uses
sample-rate conversion without informing you, so if you recorded the
speaker and microphone signals at different times you might have some
alignment issues that can't be solved by simple shifts.
If none of these is the cause, it's possible your speaker has too much
distortion.
Bob
Reply by alexpazh●September 27, 20112011-09-27
>My question should have been posed in a different way. What I meant to
>ask was if somebody could try and listen to the audio files and
>suggest why the AEC doesn't work for these particular audio files.
>There is nothing to debug in the code as it has been compiled (into
>MEX or what ever it's called). The algorithm works fine for other
>audio signals I have tested with, but for this particular set of
>signals it doesn't work...So I'm wondering what it is about these
>audio files that seperate them from others.
>
>
Hi, John! I spent some time experimenting with your code.
It looks like this particular adaptive filter is unable to adapt to this
particular path between loudspeaker and microphone.
Unfortunately I don't know why it is so.
But when I process "testSpk" signal with FIR filter, which models Room
Impulse Response, and then use this processed signal as microphone signal,
then everything works just fine and this modeled echo signal fades quite
fast.
Did you record these signals yourself? How many loudspeakers were in the
loudspeaker-mic path?
And what do you mean by "other audio signals I have tested with"?
Can you upload these "normal" signals too?
Were these other signals recorded using same mic, room and loudpeaker(s)?
Anyway, if you will find out why AEC doesn't work in this case, please post
answer here.
Reply by John McDermick●September 26, 20112011-09-26
>
> Because you haven't thought out the algorithm before you wrote the
> script, or because you haven't learned yet how to debug Matlab. �If you
> had thought out the algorithm, you'd know that you could ask reasonable
> questions about the algorithm but not the code -- and you would be asking
> specific questions about the algorithm. �If you knew how to debug Matlab
> code, you'd already know ways to break the code down into smaller pieces
> and make sure each one works. �And you'd know that debugging such code is
> _work_, and more than you can expect someone to do on USENET for free.
>
My question should have been posed in a different way. What I meant to
ask was if somebody could try and listen to the audio files and
suggest why the AEC doesn't work for these particular audio files.
There is nothing to debug in the code as it has been compiled (into
MEX or what ever it's called). The algorithm works fine for other
audio signals I have tested with, but for this particular set of
signals it doesn't work...So I'm wondering what it is about these
audio files that seperate them from others.
Reply by John McDermick●September 26, 20112011-09-26
> Because you haven't thought out the algorithm before you wrote the
> script, or because you haven't learned yet how to debug Matlab. �If you
> had thought out the algorithm, you'd know that you could ask reasonable
> questions about the algorithm but not the code -- and you would be asking
> specific questions about the algorithm. �If you knew how to debug Matlab
> code, you'd already know ways to break the code down into smaller pieces
> and make sure each one works. �And you'd know that debugging such code is
> _work_, and more than you can expect someone to do on USENET for free.
>
My question should have been posed in a different way. What I meant to
ask was if somebody could try and listen to the audio files and
suggest why the AEC doesn't work for these particular audio files.
There is nothing to debug in the code as it has been compiled (into
MEX or what ever it's called). The algorithm works fine for other
audio signals I have tested with, but for this particular set of
signals it doesn't work...So I'm wondering what it is about these
audio files that seperate them from others.
Reply by Tim Wescott●September 26, 20112011-09-26
On Mon, 26 Sep 2011 07:36:19 -0700, John McDermick wrote:
> Hello,
>
> Could anybody take a look at this matlab script and tell me why MATLABs
> echo canceller just doesn't cancel the echo in the test signal I am
> using.
>
> https://skydrive.live.com/redir.aspx?
cid=a84b49958d99df9e&resid=A84B49958D99DF9E!102
Because you haven't thought out the algorithm before you wrote the
script, or because you haven't learned yet how to debug Matlab. If you
had thought out the algorithm, you'd know that you could ask reasonable
questions about the algorithm but not the code -- and you would be asking
specific questions about the algorithm. If you knew how to debug Matlab
code, you'd already know ways to break the code down into smaller pieces
and make sure each one works. And you'd know that debugging such code is
_work_, and more than you can expect someone to do on USENET for free.
--
www.wescottdesign.com
Reply by Vladimir Vassilevsky●September 26, 20112011-09-26