similar to: Speex Options

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

Hi, I am using speex-1.2 beta1 version. When I am using sample files from http://www.surfnonstop.com/~bandit/speex/echocard1/ ,example 6, as input to mdf through testecho the output is fine However when I am recording the signals in echocancel.cxx in OpalEchoCanceler::ReceivedPacket taking speaker signal from echo_buf and mike signal from ref_buf, echo cancellation is not affective. Can

Hi All, I am getting this error during make. please help me./ speexec.c: In function `speex_ec_process': speexec.c:112: syntax error before "noise" cc1: warnings being treated as errors speexec.c:133: warning: implicit declaration of function `speex_echo_state_reset' speexec.c:148: warning: passing arg 5 of `speex_echo_cancel' makes pointer from integer without a cast

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 big (if you don't know what I'm talking about, RTFM) 4) The capture and playback are done on the same device (synced clock) Jean-Marc gorun.butail@wipro.com a ?crit : > Hi all, > > > > I

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

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

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.

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.

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

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.

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

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

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, For my VoIP application machine A sends speex encoded audio of to machine B and vice versa at. Data is captured in PCM 8Khz, 16 bit and then encoded using speex 1.1.12 The packet A played and the packet A captured through mic are the input to speex echo canceller. So I am trying to remove traces of packet A played from the captured data. I have followed example testecho.c All I hear is some

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

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

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