similar to: echo residue buffer size

Jean-Marc Valin wrote: > I suggest you have a look at the new API I introduced in svn (see > testecho.c). It's easier to use, harder to screw up, and it means I can > improve it in the future without breaking things. > > Jean-Marc Thanks for your response. Yes, I followed The World Institute for Mental Health recommendation. :) But I think the problem might still present

Hi Ted, Thanks a lot for this analysis. > In FLOAT_DIVU() it hangs at the following: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate =

Hi Jim, I've just been made aware of these problems (look for the thread "speex echo cancellation limitations"). It's on my short-term TODO list. > If fftwrap.c, I ifdefed out the spx_fft_float and spx_ifft_float routines, > because there were not used and required smallft.c (which is not so small at > all) to be added to the build. Right, need to cleanup that

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.

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

> I am writing to gain a better understanding of the limitations of speex echo > cancellation, esp. with respect to the fixed point implementation. > If these limitations have been documented elsewhere already, please let me > know! Nothing officially documented, sorry. > I observe experimentally that when one or both of the echo or ref data for > speex_echo_cancel() have

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

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not

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 Folks, I am having trouble using speex_echo_cancel. As a starting point, I am using the testecho.c source code. I compiled the 1.2beta1 version. I have not tried any other versions of speex. The document says that the order of arguments to Speex_echo_cancel is (echo_state, input_frame, echo_frame, output_frame, residue) where "input_frame" is as captured from mic and

Hi I just upgraded to http://svn.xiph.org/trunk/speex r10357 and got this build warning: alfredh@io:$ make -s mdf.o libspeex/mdf.c: In function 'speex_echo_cancel': libspeex/mdf.c:321: warning: statement with no effect libspeex/mdf.c:317: warning: `adapt_rate' might be used uninitialized in this function Is this intentional? In any case here is a simple fix: Index:

Probably the level of your signal is too low and/or you're just not letting it time to adapt. Jean-Marc Le mercredi 19 juillet 2006 ? 19:00 -0400, ac2491@columbia.edu a ?crit : > On closer looks and debugging I always end up in > > speex_echo_cancel function with comment > /* Temporary adaption rate if filter is not adapted correctly */ > > > Does this give any clue

Hi, If I pass the same ref and the echo data to the echo cancellation API, I am expecting silence as output. I get back the original audio data. Is this correct? Thanks -Anurag Quoting ac2491@columbia.edu: > Hi Jean, > > I got the earlier problem fied with correct NN and tail values. > But > I dont see any echo being cancelled. To the echo cancel API I am > giving, audio

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: compare.JPG Type: image/pjpeg Size: 23993 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20080123/894fc8a1/compare-0001.bin

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

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

Hello everybody. I have the same problem like you. I use ARM microcontroller too. Here is the list of all functions called by speex_echo_cancel until goes into infinite loop: speex_echo_cancel() | spx_fft | kiss_fftr | kiss_fft | kiss_fft_stride | kf_work Function kf_work looks like: static void kf_work(kiss_fft_cpx * Fout, const kiss_fft_cpx * f, const size_t fstride, int

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 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.

Just tried your files and I'm not running into any infinite loops and the cancellation works fine. Unless the C6x has the same problem, I suspect a 16-bit problem. I'll check and see if I find something. About the r=0 problem, I can't find where it ends up in a denominator, so I suspect is not (directly) the problem. Jean-Marc Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?crit