similar to: Double talk detection with AEC

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

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,

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 >

Hi, Arun and me are working on a echo-canceler module for pulseaudio build around speex. When using the preprocessor's echo filter, specifically in combination with denoise and AGC, it's unclear whether these have to run before or after the AEC. Right now we've got one instance of speex_preprocessor doing AGC and denoise running before the echo canceler; and a second for echo

I have tried both linear and non-linear (residual echo) parts of SPEEX AEC on MS Windows platform. Great job. Most echo can be cancelled. However, the voice volume becomes too small. Does any one have suggestions that makes voice volume louder but echo still can be cancelled? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello! I'm attempting to implement Speex AEC support in GStreamer, using work started by Olivier Cr?te. In the Speex manual, I see this text: "Using a different soundcard to do the capture and plaback will *not* work, regardless of what you may think. The only exception to that is if the two cards can be made to have their sampling clock ``locked'' on the same clock

Robert Benjamin <benjie1 at cox.net> wrote: >Sent: Oct 13, 2010 4:26 AM >To: wine-users at winehq.org >Subject: Re: [Wine] Fwd: Re: Any progress on bug 16147? > >Just wondering why I haven't had a reply about the webcam problem >with iSpQ and icuii. There are a few previous posts about testing the >cam from Gert but nothing lately. Maybe because no one is working

> Today's Topics: > > 1. AEC with WB mode (Jean-Christophe.Berge@etu.enseeiht.fr) > 2. Multiple frame encode and decode (Reza Fatahillah) > 3. cant link speex_echo.h (jesus) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 20 Sep 2006 08:46:03 +0200 (CEST) > From:

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

speex-devDear Jean-Marc Valin I got some problems with evaluating the AEC module of speex. I wrote a test main function and compiled it with the speex lib in VC6.0, it initialized the AEC state and called the AEC main function in the same way as what was done in testecho.c. The near-end input wave file was a simple delaying and adding version of the far-end input wave, eg. y(n) =

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

I actually forgot to mention that I'm using ultra-wideband mode, but seems like you understood that anyway. Is this true that Speex echo cancellation only performs well in narrowband mode !? I've been using 100 ms as the default tail length. I don't know what the ideal tail length would be. I have tried shorter and longer tails but it hasn't made any difference. Does

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

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 2010-03-16 14:22, Josh Gargus wrote: >> If more than one speaker receives the *same* signal, it doesn't >> matter the number of speakers. It only gets tricky when the >> speakers are playing slightly different signals (e.g. from a stereo >> song). > > Does "tricky" mean that the Speex AEC won't handle such situations > well? Or just that you

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

> Yes, you are not forced to reset the AEC between calls at all, if you > can assume the actual echo path (physical environment) will not change > much, you can keep the instance and continue using it for the next call. > > Also what we did was keep the AEC running between calls - but we had a > rather high-duty system with sounds and signals played between calls, so > the AEC

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,all I have tested AEC on files, it works well.I have some files,one is echo file, others are echo-added files(an origin file adding echo at different delay,such as 20ms,40ms...120ms,140ms).AEC do wonderfully on those files except echo added at 140ms-delay. But ,when i use AEC in my voip project, it does feebly. Who can give me some hints why caused this.How long can sound be picked up by