similar to: DPLL in aec samples

OK, I'm tired of arguing. All those who think they're going to do AEC on different un-synced cards, just go for it. However, please do not complain and/or ask questions about that on this list. AEC is already a hard enough problem when you have a sane sound setup that I see no point in trying to do anything with drifting clocks. As for soundcards with different clocks for in and out, I

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

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 >

Simply to say, in a quiet room, you can play a impulse signal and then find it's impulse response signal from the microphone. For example, if the delay between the impulse signal and its response signal range from 500 to 3000 cycles, you can buffer the far-end signal to 0-300 cycles and set the filter length to 4000. It is also called to align far-end signal and near-end signal. BTW: Speex

Hi Shridhar, Sample rate conversion is not enough to solve this problem. I have tried this method several months ago. The first step is to measure the difference between sample rate of capturing and rendering. Then resampling (by what you said "sinc interpolation") one signal to eliminate the difference. The frequency step in my experiment is less than 0.1Hz. I have tried speex AEC

On 04/13/2011 02:58 AM, Shridhar, Vasant wrote: > I am doing this right now with no problem. I am not using speex for this at the moment though. Group delay is the biggest problem. I implemented a version where the input and output sample rates are known up front. The routine than interpolates between the jitter. This should solve the problem. The crystals used to clock the input and

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

Hi all, We all know that mismatch between clocks of ADCs of far-end voice and near-end voice is not allowed in a time-domain or frequency-domain LMS based AEC system. It means that capture and render audio streams must be synchronized to a same sample rate. However, I found that this restriction is removed in microsoft AEC from Windows XP SP1. Anyone knows how microsoft AEC do it? This technology

When updating the speex sources from svn tree, I found that the following revision has corrupted the deallocation (segmentation fault): ------------------------------------------------------------------------ r9320 | jm | 2005-05-27 15:05:05 -0300 (Fri, 27 May 2005) | 2 lines Proper de-allocation When compiling with the 9316, everything works fine. but when I update with later

Hi all, We have discussed so many about sampling rate asynchronous (or offset) between rendering (D/A converter) and capturing (A/D converter) of most PC soundcards. It seems all acoustic echo cancellers, include AEC in speex, can not deal with this trouble, because it causes a drift of echo path and also buffer overflow and underflow which jumps the delay of echo path seriously. Unfortunately,

The problem with different sound cards is that their clocks are not usually synchronized, and therefore the clock drift adds a non-linear factor to the audio path. The AEC can only cancel linear changes to the audio path, and so the AEC never converges.One solution is to measure the clock drift and resample either the input or output signal so that they *are* synchronized, and then the AEC

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

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, I am looking for AEC software which can be run on the server side. This means there will be a fairly constant 600ms or so gap between sending out an audio frame and getting it back with echo. Could Speex AEC be configured to handle these conditions? If so, how good can I expect it to be? Thanks --------------------------------- Yahoo! Mail is the world's

> 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

AFAIK, that's a common point for all AECs. But some of them solve the problem by resampling on of the end to keep it in sync with the other. On Tue, Jul 7, 2009 at 5:14 PM, ggb<ggb at tid.es> wrote: > Thank you John. > > On 07/06/2009 11:03 PM, John Ridges wrote: > > ly synchronized, and therefore the clock drift adds a non-linear > factor to the audio path. The AEC

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

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

> In those cases, when you get let's say 1000 packets of 20ms from the mic > you may have only 990 packets of 20ms from RTP incoming stream. > > Thus, before sending outgoing mic/RTP stream, you would wait for 1000 > incoming packets: where last packet in fact arrive 10*20ms = 200ms > after it was supposed to. I have from my experience already seen 4s > of clock deviation

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.