similar to: AEC with different soundcards

Hi ? I used this "sample counting " method to?resample and put my audio signals in synch. It worked perfectly?in XP machines using a SoundMax?audio card, but it failed in other XPs using Realtek cards. As seen on http://lists.xiph.org/pipermail/speex-dev/2008-September/006889.html?my application?continously checked my AEC level to slighly modify resample frequency, but convergence was

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

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,

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

> 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

Hi, Speex devs, I apologize in advance if this is not the proper venue for this question, but I had seen in the archives that other threads of this nature had been discussed. In brief, I'm trying to get AEC working on a simple Android NDK app. It's a basic "play from a file, record from the mic to file" loopback test. I'm using OpenSL ES. I establish a player and a

> 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

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

Hello, I'm using AEC for a VoIP application on mobile handsets. I am doing experiments to learn how to work with it, and I have a problem: As long as I play through the device's normal speaker and record using the mic, I have absolutely no clock drift (according to echo_diagnostic.m). The echo is being cancelled and all is fine. Once I route to the earpiece (and still use the mic, which

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

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 Steve, Have you read this paper? (Heping Ding, David I. Havelock, Drift-Compensated Adaptive Filtering for Improving Speech Intelligibility in Cases with Asynchronous Inputs. EURASIP J. Adv. Sig. Proc. 2010:) Let me call is paper-Drift. It provided a method to evaluate Relative Sample Offset (RSO, d[i]) which is omitted in the microsoft paper (Challenges and Solutions for Designing Software

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

Hi Steve, > I don't know if this has only recently been put on line, but I never > noticed it until today - > www.iwaenc.org/proceedings/*2008*/contents/papers/9044.pdf > > That paper is from people at MS describing, in some detail, what the > Windows kernel echo canceller does to handle synchronisation issues. It > tracks both time varying sample clock drift and hiccups

Tabitha Flash a ?crit : > 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? Just use a ring buffer to put the delay back to normal. > If so, how > good can I expect it

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. That's way too much to do anything useful because the tail doesn't even "see" the echo. You need to reduce

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