similar to: speex-1.2beta1 AEC garbles up audio unless compiled with --enable-fixed-point

I'll try to make some shorter samples later, but for now here are the ones I have tried with: http://www.surfnonstop.com/~bandit/speex/1.2beta1_AEC_garble/ The original recordings are in mic.raw and spk.raw. Jean-Marc Valin wrote: > You may have triggered an instability problem. Can you upload your files > somewhere so I can have a look at them? > > Jean-Marc > > Andras

You may have triggered an instability problem. Can you upload your files somewhere so I can have a look at them? Jean-Marc Andras Kadinger a ?crit : > 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

When you say inverted, do you mean a) input and output exchanged with each other, or b) input or output having changed sign numerically (e.g. multiplied by -1)? Andras Jean-Marc Valin wrote: > Make sure that: > > 1) You're using svn head, which has many improvements > 2) The AEC inputs aren't inverted > 3) The delay between the near end and far end signals isn't too

Andras Kadinger wrote: > I have now found a testcase where SVN AGC starts out good, but then it > keeps increasing the gain but never decreasing it, and eventually goes > out through the roof, during the same single recording. I've been doing massive changes in the svn preprocessor, so I'm not too surprised I broke the AGC, because I haven't updated it. Did it also do that in

Perhaps you could add a warm-start to the AEC, such that the parameters start near the correct values on all but the first use? Stuart On 05/25/2011 08:22 AM, Andras Kadinger wrote: > 2011.05.25. 4:52 keltez?ssel, Arun Raghavan ?rta: >> On Tue, 2011-05-24 at 11:09 -0400, Jean-Marc Valin wrote: >>> The fact that the AEC takes a few seconds to converge is normal. The >> Do

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.

Hi Andras, others, Andras Kadinger <bandit <at> surfnonstop.com> writes: > > > Daniel, > I recommend you to start from a simple case and gradually progress > towards your goal. > Can you make things work with the "Speex in a Disco" (Example 6) > testcase at http://ns.surfnonstop.com/~bandit/speex/echocard1/ ? > These files

On Tue, 2011-05-24 at 11:09 -0400, Jean-Marc Valin wrote: > The fact that the AEC takes a few seconds to converge is normal. The Do you think there might be a way to reduce this? > fact that it needs to completely re-converge in the middle of a call > probably indicates that something went "wrong" in the audio > capture/playback. For example, that could be an

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.

The echo suppression in SVN is shaping up quite nicely! I have also observed some - occasional, apparently data-dependent - misbehaviour in AGC. http://www.surfnonstop.com/~bandit/speex/echocard1/

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

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

Hi all, I have been trying to implement audio echo cancellation using mdf.c from opal-2.2.2. Using testecho.c the output obtained is not satisfactory. It is cancelling the far end signal instead of the near end signal as per requirement. I have been moving in circles figuring how to approach the problem. Is there something wrong with the mdf that I am using? I would be really thankful if

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

speex-devDear Jean-Marc Valin I got some problems with evaluating the AEC module of speex. I wrote a test main function and compiled it with the speex lib in VC6.0, it initialized the AEC state and called the AEC main function in the same way as what was done in testecho.c. The near-end input wave file was a simple delaying and adding version of the far-end input wave, eg. y(n) =

I would like to add AEC to my program. Since the nature of my program is such that its playback and recording are asynchronous. I have no idea whether the testecho.c example will work for me. Anyone here has experience with the AEC in async mode? YUN TAO

Terrific! The patch fixes my problem quite decisively. I will want to use this with a 16K sample rate. Is it expected to work well with just another slight patch, or will we need to modify it more deeply? Also, are there any tunable parameters besides tail length? I am wondering about the aggressiveness of adaptation and I know you are an expert in that area. Thanks so much, Michael

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