similar to: AEC initial convergence (Mark Pietras)

I'm wondering if there's a way to speed up the initial convergence time. Maybe I'm completely off base here, but specifically I was wondering if the code starts the search assuming the echo is near to zero milliseconds, and works towards longer to find the cancel point. If so, is there a way to have it reverse the search, that is, start with the assumption that the echo is furthest

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

The client is the adobe flash player. No install and on 98% of all desktops but we can't change it. It works ok if people use headphones but we need to stop the howl than can build up if more than one person in a conference has mic to close to speakers. Any ideas? Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > 1) Is it ok if the audio is encoded (using

>> Actually, computing the "power spectrum" for each frame of W shows >> how large an ammount of the original signal at time offset j the >> echo canceller thinks should be removed from the current input frame. > > Careful when looking at W because of how the real and imaginary parts > are packed in the array. Err. Ok, as I got it, 'bin 0' has it's

> Err. Ok, as I got it, 'bin 0' has it's amplitude in W[0], bin 1 to N-1 has > it's real part in W[i*2-1] and it's imag in W[i*2], and finally the > nyquist amplitude is in W[N-1] Not quite, it's packet "real, real, imag, real, imag, ...". > I took this from how power_spectrum() computes, so I might be off :) But power_spectrum() handles that

> 1) Is it ok if the audio is encoded (using Nelly Moser ASAO) and sent > to the client and decoded when it is recevied so the AEC is always > performed on raw PCM16 8KHZ ? No. The entire path from AEC to loudspeaker and from mic back to AEC must be free of any non-linearity, codec, drift, ... > 2) The audio is moved in 32ms (512 byte) chunks and the reading and > writing to the

On 04/04/2011 06:58 PM, Simon Morlat wrote: > Hi, > > I implemented a small patch that allows the internal convergence state > of the echo canceller to be saved in a file for later use, especially > after a process restart or machine reboot. This enables immediate echo > cancellation the second time the AEC is run. > > Of course this works only if the acoustic environment

Hi, I implemented a small patch that allows the internal convergence state of the echo canceller to be saved in a file for later use, especially after a process restart or machine reboot. This enables immediate echo cancellation the second time the AEC is run. Of course this works only if the acoustic environment of the device doesn't change and if the soundcard latency is constant. To use

On 04/14/2011 07:26 PM, LiMaoquan2000 wrote: > Hi All, > Many Thanks to Underwood for her excellent review of our big trouble > which prevent LMS-based AEC algorithms to be used in most computer. > Maybe it can be summaried as follows: > 1. Different sample rate of sampling and rendering does exists in most > low-cost soundcards (In my experiments over more than 20 soundcards,

Steve U., Thanks for the quick response. I will look into OSLEC for the Hybrid case. With regards to using the last known good set of coefficients for re-use, I am assuming that any changes in the echo path would be minimal to none (in the hybrid case of course) and therefore if my system was reset, only a small amount of convergence would be needed if at all. Of course I am basing my

Hi All, Many Thanks to Underwood for her excellent review of our big trouble which prevent LMS-based AEC algorithms to be used in most computer. Maybe it can be summaried as follows: 1. Different sample rate of sampling and rendering does exists in most low-cost soundcards (In my experiments over more than 20 soundcards, the differences range from 0.5Hz to more than 50Hz when sample rate is set

Hello, I'm from Korea and I'm trying to implement realtime AEC with 2 computers and using speex. Actually , It works well with 2 computers and they are communicating.(It looks like double-talk but actually one aec and preprocessing algorithm is running in each computer) Anyway the problem is after processing(I'm using aec and preprocessing for noise suppression), the output

Hi, I already implemented and posted a patch to do this serialization a few weeks ago. http://permalink.gmane.org/gmane.comp.audio.compression.speex.devel/6913 It is not integrated into the main git tree though. Regards, Simon On 26/05/2011 21:21, Stuart O Anderson wrote: > This is not part of the current API. It shouldn't be too hard add a > serialization routine for

Hi Jean-Marc, Regarding you points: 1) Is it ok if the audio is encoded (using Nelly Moser ASAO) and sent to the client and decoded when it is recevied so the AEC is always performed on raw PCM16 8KHZ ? 2) The audio is moved in 32ms (512 byte) chunks and the reading and writing to the AEC code will be done by separate threads at regular 32 ms intervals. 3) Occasionaly audio is

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

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

Aymeric Moizard a ?crit : > > I'm working on the echo canceller with the SVN, with Windows Mobile 5 > PocketPC. > > Obviously, I can't make it run correctly. What happens/doesn't happen? > My question: If I use the SPEEX_PREPROCESS_SET_ECHO_STATE, I have > changes in the sound: noise seems to be removed. Noise should be removed even without

Hello, We've integrated the speex echo canceller into PulseAudio, and coupled with the AGC/denoiser, it works reasonably well and has been a breeze to plug in, so thank you! One thing we're seeing, though, is that the canceller seems to take some time (a few seconds) to "learn", so initially the echo is clearly audible and it slowly fades out. This sometimes occurs in the middle

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

Jim, You're right, the memset really is there, how could I miss that? :) I also spoke too soon, as my change doesn't solve anything. At each run, something random causes the algorithm to either work or not work at all. There is a correspondence between whether the echo cancel works and whether the st->PHI and st->W arrays contain data or zeroes. (the arrays contain zeroes when alg