similar to: AEC learning behaviour

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

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

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

On 06/22/2011 04:57 AM, Arun Raghavan wrote: > On Tue, 2011-06-21 at 11:39 -0700, Arun Raghavan wrote: > [...] >> I'm also running this on x86 (x86_64, technically), and it's all >> floating-point, so I guess this is a regression somewhere. Will try to >> see if I can run it without any optimisations if possible, which I >> assume should serve as an adequate

What is the current status of the residual echo suppressor in the preprocessor? I ask this because I have occasional problems with the AEC, in which it fails to cancel echo. I think the problems have to do with samples being dropped by the audio IO system, which is effectively impossible to detect and counteract reliably. A colleague recommended using an echo suppression technique (which he

> As you can tell, the AAGC integration with speex was really a classic > hack. Instead of re-creating the hack, what's probably best here is to > integrate AAGC back into speex, and have a proper API. Agreed here. If you can come up with a clean patch to add that feature, it's something I'd like to see in Speex. > For those of you just tuning in, what I call

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

2010/5/11 Elston Sa <jose at rebaca.com>: > Is there an API in speex or have you implemented your own? I don't know if there is an API in speex for this, probably not. There is a test for AEC which does something very similar. I implemented it starting from a FFT library. It is quite easy to do. > > I am currently trying to find one. But if you could point me to one it will

Hi Andras, others, Andras Kadinger <bandit <at> surfnonstop.com> writes: > > > Daniel, > I recommend you to start from a simple case and gradually progress > towards your goal. > Can you make things work with the "Speex in a Disco" (Example 6) > testcase at http://ns.surfnonstop.com/~bandit/speex/echocard1/ ? > These files

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

> I hate to be a talker and not a do-er, but I won't be able to write this > myself, probably someone on the iaxclient team could do it. Anyway, let me know if/when someone's working on that. >> Hmm, or does that mean the analogue AGC is actually completely >> independent from the "real" AGC. Any thoughts? >> > > It's actually a bit more

Hi Aymeric, > 2 questions: I count 4 :-) > * Do you "feel" that the current svn is enough stable Yes. I'm planning on releasing it as 1.2beta3 this week. Even in normal time, I try to keep svn in good shape so it is almost always better than the last release. And even when it breaks, Speex bugs tend to be very obvious and easy to reproduce (no segfaults that happen once a

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

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 you think there might be a way to reduce this? The shorter you make the tail length the faster it will adapt. But this will make it more important to reduce HW/SW latency so that you don't waste

> 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

On Tue, 2011-06-21 at 20:18 +0200, Kadinger Andr?s wrote: > 2011.06.21. 19:22 keltez?ssel, Arun Raghavan ?rta: > > Hi Andras, others, > > > > Andras Kadinger<bandit<at> surfnonstop.com> writes: > >> > >> Daniel, > >> I recommend you to start from a simple case and gradually progress > >> towards your goal. >

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

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

May I still try to sync them using some kind of DPLL (digital phase locked loop) mechanism? Something like matching clocks and interpolating samples to try to sync them together? Do the interpolated samples get to be eligible for an aec in your opinion? Thanks, Dario > To everyone on the list: do *NOT* attempt to do echo cancellation with > signals sampled using different clocks. This will