similar to: accessing AEC delay estimate?

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

Hi, I plan to use AEC for a live performance, storytelling for very young children (and their parents!) in a mongolian yourte . Actually the storyteller can make vocal loops, there is an omnidirectional microphone in the center of the yourte, 5 loudspeakers in a circle along the yourte's wall and Pure Data in a linux box. And now she wants to make vocal loops over music and loops over

Hi I've been debugging and troubleshooting echo cancellation myself recently and I have made some observations. First of all playback and recording must be synchronized. There cannot be any clock drift between the microphone signal and the speaker (echo) signal. This has been said many times in the mailing list, but I will repeat it anyway. You have to first make sure that this is not your

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

Hello, I was looking at the old emails on this mailing list concerning problems with AEC when having playback and capture at different sampling clock. Several propositions came along like: * Cross correlation * clock skew estimation * sample interpolation * resampling the signal * ... I would like to know whether a working solution has been found as today or are we always bound to use a sound

Hi Jean-Marc, thanks for the response. First, I will clarify again that floating-point solves this - so isn't that a bug in fixed-point? Also, I understand that algorithmically the AEC won't cancel echo properly on a non-linear signal, but why completely distort the output? If the echo just won't get cancelled it would be acceptable, but in the current state it disables the ability to

Hi, The Speex AEC is simply not designed to deal with non-linear echo, as is the case when clipping of AGCs are involved. Make sure all your path is linear or forget about the Speex AEC. Jean-Marc On 11-01-03 11:31 AM, Omer Gilad wrote: > Hi, > I couldn't find a discussion that specifically addresses this, so here > it is. > > I'm using Speex AEC in my mobile VoIP

Hi, I couldn't find a discussion that specifically addresses this, so here it is. I'm using Speex AEC in my mobile VoIP application to cancel speaker echo. The used version is 1.2rc1 from the website, and I'm compiling with fixed-point. On most occasions, the AEC works very well and cancels most of the echo (combined with the preprocessor). On some devices, where the microphone signal

Hi all, I am attempting to test AEC behavior at various sample rates. I ran a little experiment: I recorded a 10 seconds voice clip and the resampled at 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000. I have a small applications that plays a wave file, records whatever comes in from the microphone and applies the Speex AEC and preprocessor on the input. It then saves the raw

Try using SPEEX_ECHO_SET_SAMPLING_RATE to specify your sampling rate. Also, don't forget that the tail need to be longer (proportional to the sampling rate). Last thing, if you use resampling, make sure you use a decent resampler (the Speex one is fine) because otherwise, any aliasing left will not be cancelled. Jean-Marc Mihai Balea a ?crit : > Hi all, > > I am attempting to test

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

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.

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 you think there might be a way to reduce this? The shorter you make the tail length the faster it will adapt. But this will make it more important to reduce HW/SW latency so that you don't waste

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

The fact that the AEC takes a few seconds to converge is normal. The 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 overrun/underrun in the soundcard buffer, or the user changing a volume control after the AEC, or moving the speakers, ... anything

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.

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 >

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

I've recently made changes to the AEC. Please try the code in SVN and see if it works better. Jean-Marc Le jeudi 03 novembre 2005 ? 22:36 -0800, Jason Harper a ?crit : > 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 >

Hi, my VoIP system uses speex with framesize = 160 samples(20 ms) at 8khz, sending and receiving paquets of 1600 samples(200 ms). When I receive a packet, I buffered it (I have also tried with speex_echo_playback) before sending to the speaker. When I capture from microphone, I fist remove DC offset (I saw in OPAL sources) and then I call speex_echo_cancellation for every one of the 10