similar to: AEC initial convergence

> 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, and works longer to find the adapted point. If so, is there a way > to have it reverse the search, that is, start with the assumption that >

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

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

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, The notch filter in AEC is only used to remove DC signal, and the time of convergence is not important, right? If so, I think preset value of notch_radius is too small, and it causes noticeable distortion(freq < 200hz cut). There is a picture in attachment to show signals under different radius in time-domain. By setting notch_radius to 0.999 for all sampling rates, I found better

First of all, thank you for your input Tim. That is very helpful. I would love to hear from other people with experience of AEC and Speex. I guess I have to split my question into to parts now. 1. Is it a fact that using the windows multimedia API (wave audio) for audio capture and playback makes it impossible to do echo cancellation with Speex AEC or other EC method due to inprecise timing? I

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

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 Jean-Marc, You make that sound like its just a matter of meeting some arbitrary spec. Let's be more specific..... If you use narrow band voice down to deep bass frequencies: - 16 bit linear audio sounds good - alaw or ulaw sounds muddy - low bit rate codecs, like speex or G.729, sound awful. I assume QinBin only listened to some uncompressed audio in his evaluation.

A couple months ago, there was a thread discussing various opinions for directory structures for including xenlinux code into the Linux tree. (The current structure is not architecture independent and also uses some names/terminology that might need to change to be more acceptable to Linux kernel developers.) I think Chris Wright said at the time that he would be working on a patch to

Hi, But in fact, it really affects the voice quality. One of my tester says, "Is your mouth far way from the mic?" Could you explain why we should cut 200hz below? >The notch filter is specifically designed to cut below 200 Hz when >working in narrowband. In wideband, the cutoff is more around 50 Hz. The >reason is that in narrowband operation (irrespective of the

The notch filter is specifically designed to cut below 200 Hz when working in narrowband. In wideband, the cutoff is more around 50 Hz. The reason is that in narrowband operation (irrespective of the codec), you're not really supposed to have anything below ~200 Hz, but a lot of people forget that. Jean-Marc On 2010-03-03 02:40, brant wrote: > Hi, > > The notch filter in

On 03/03/2010 10:22 PM, QianBin wrote: > Hi, > > But in fact, it really affects the voice quality. One of my tester says, "Is your mouth far way from the mic?" > Could you explain why we should cut 200hz below? > We already said it affects the quality when the voice is compressed. Are you asking why that should be? Even with a simple form of lightly lossy

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

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

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

I've been testing the AEC and have experienced it working on one sound card, and not working when using different cards for capture/playback so I know it's a real problem. And yes I know the documentation says it won't work "regardless of what you may think." I'm the inquisitive type; I'm looking to understand just what exactly is happening here. One discussion in

The AEC is not designed to cancel sinusoids. Try with speech. Jean-Marc Johnson Peng a ?crit : > 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. >

Hello all, I am fitting a Gamma distribution to some data I have using nls(). The function obviously runs into issues when using a 0 as a parameter value. I understand the line alg = "port" can be used to set the lower bounds to prevent this from happening. When I run the code I get the following: Algorithm "port", convergence message: relative convergence (4). I have