similar to: AEC params

I ran some further tests on mdf and here are the results: 1. reduced tail length to 100ms, aligned mic and speaker signals to within 10ms - almost no echo attenuation 2. aligned mic and speaker signals to within 5 samples - still almost no echo attenuation 3. ran testecho using the same file for mic and speaker - very good echo cancellation (of course this is expected, but I needed to do a sanity

I'm pretty much sure of it. When I test inverting the inputs, my output is pretty much the same as my speaker signal. Whereas the way that I normally test the output is my mic signal with very little attenuation. If you are interested I can send my test files; they are about 94KB each. -Jason --- Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Are you sure you're

Hi: By 'no success', I mean result gets worse in terms that, there comes in a shrill noise with high gain and also *no* attenuation of the echo. I am trying to validate the DC offset part. But can you please feed some light on how does the DC offset matter for AEC. As I have already mentioned, I tried adding silence (from 2 ms to 10 ms) in the start of the reference signal. This is for

Thanks for alerting me to the new changes. I just tried the latest code from SVN, but unfortunately I still have just about the same results. The estimated echo that gets subtracted from the actual echo is such a small signal that it doesn't really result in any noticeable echo attenuation. I currently have my filter size set to 2 seconds even though the echo in my microphone file is only

Had a try. The reason why a simple delay is not that good is mainly due to the initialization of the filter parameter that still takes a few seconds (if they are perfectly in sync, you sort of get lucky). Otherwise, you real recording seems to have something odd in it. Are you sampling from a different card then the one that's playing the sound? or maybe the mic (or something else) in the room

I've tried some further debugging to see what mdf is actually doing. Instead of sending: tmp_out = (float)ref[i] - st->y[i+st->frame_size] to the output, I just sent st->y[i+st->frame_size] to see what was being subtracted from the microphone input. When I open this in Audacity, I see a very small signal at about -40dBm. The actual echo in my sample has a power closer to -20dBm.

Le vendredi 11 novembre 2005 ? 01:21 -0800, Duane Storey a ?crit : > This is a very real problem though.. I've encountered many sound cards that > use different clocks for input and output (even on the same card!) Also, if > you open up a sound device on windows at 8kHz, the microphone is often > around 8100Hz, while the output is 8000Hz.. I'm not sure if there's a bug >

To everyone on the list: do *NOT* attempt to do echo cancellation with signals sampled using different clocks. This will *NOT* work. Just a 0.1% difference between the two sampling rates (it's sometimes worse than that) means that the impulse response drifts by 8 samples every second. There's just no way to efficiently track this. Or at least no way that doesn't involve something 100x

Are you sure you're not just inverting the two inputs? Jean-Marc On Wed, 2005-11-09 at 22:16 -0800, Jason Harper wrote: > I ran some further tests on mdf and here are the > results: > 1. reduced tail length to 100ms, aligned mic and > speaker signals to within 10ms - almost no echo > attenuation > 2. aligned mic and speaker signals to within 5 samples > - still almost

When I ran test 4 as originally described there is substantial echo cancellation (but not as good as when the files are perfectly aligned). When I invert the inputs, there is no noticeable cancellation. I'm using testecho with the preprocess line commented out. Preprocess seems to work very well at cleaning up the residual echo when mdf does its job, so I'm just focusing on testing mdf.

This kind of behaviour is odd. One of the reason could be the fact that you're using a really long impulse response. Try syncing your signals and making the tail length more in the order of 100 ms to 300 ms. Jean-Marc Le dimanche 06 novembre 2005 ? 21:25 -0800, Jason Harper a ?crit : > Thanks for alerting me to the new changes. I just > tried the latest code from SVN, but

Hi: I have been trying to test the speex AEC by playing a voice sample (pre-recorded) as a echo and capturing a new voice sample and playing the pre-recorded one, for reference. [Sampling rate 8 KHz, frame size 64] For some reason, I dont see any removal of echo. Does anybody have a idea of * Testing the AEC in some other mechanism or * Getting some sample files for testing AEC Thanks Su ---

On Mon, Aug 11, 2008 at 12:34 PM, Jean-Marc Valin < jean-marc.valin at usherbrooke.ca> wrote: > OK, here's what happens. There is indeed a small difference between > beta3 and rc1, but the fundamental problem isn't there. I've attached > plots of the speaker signal (blue) alongside the mic signal (green). You > can see the delay is in the order of 1000 samples.

Thanks for taking a look. There was no motion; however you are right about sampling from a different card. The speaker is connected to the Sound Blaster card, while the microphone is part of a USB webcam. I don't think that this is likely to be too unusual a configuration among users. I can retry the test using a sound card microphone to see if there is a difference. If it turns out that

This is a very real problem though.. I've encountered many sound cards that use different clocks for input and output (even on the same card!) Also, if you open up a sound device on windows at 8kHz, the microphone is often around 8100Hz, while the output is 8000Hz.. I'm not sure if there's a bug somewhere in some of the OS resampling algorithms, but I've seen that on many machines.

Hi: Can anyone give some insight on: 1) As per the Speex manual, there is a mention of the relationship between input frame and echo frame (Pg 19, Para 2). I was wondering of what would be the ideal delay between these two frames, so that the echo is already fed to the canceller and the echo cancellation filter is not inefficient. 2) Corresponding to the above mentioned delay, what filter

I wasn't implying that anyone do anything about it, just that's it a real problem. Unfortunately, most of the crappy sound cards are the ones that ship with your typical PC, so it's just something that people should be aware of. The solution is pretty straightforward -- just resample the audio data in real time using a reference clock. -----Original Message----- From: Jean-Marc

On Sat, Aug 9, 2008 at 12:59 PM, Jean-Marc Valin < jean-marc.valin at usherbrooke.ca> wrote: > Hi Benny, > > Can you send me your pair of testecho input files that work well with > beta3 and not with rc1? I'll have a look. > > Thanks for the help. The files are on their way now, the upload will take few more minutes to complete. In the mean time let me explain more

Greetings everyone, I was about to compare AEC performance between 1.1.12 and 1.2beta1 when I noticed something. If I configure (and compile) speex-1.1.12 with ./configure --enable-shared=no --enable-static=yes it compiles and works as expected: I can run a mic and speaker signal through testecho, it runs in a reasonable amount of time (about 23 secs for 3 minutes of audio) and I get back

Hi Jean-Marc, I tried with both testecho and my test program, and for some reason it just doesn't cancel any echoes with the 1.2-rc1. The testecho from beta3 binaries works fine, and also if I replaced mdf.c in 1.2-rc1 with mdf.c from beta3 and use my test program, it will work again. This happens for both 8KHz and 16KHz. Any ideas? I could upload the test samples and results if needed.