Forums

Echo Cancellation Problem (MATLAB)

Started by John McDermick September 26, 2011
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

Thank you.


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 > > Thank you. >
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
> > 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.
> 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.
>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.
On Sep 27, 6:04&#2013266080;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
> 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
> > 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 :-)
>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 > >Thank you.
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