Re: AEC learning behaviour
"Maris Engineering" <[email protected]>
| Newsgroups | gmane.comp.audio.compression.speex.devel |
|---|---|
| Message-ID | <[email protected]> |
Simon, superb! thanks for that contribution. I'll investigate it. Due to having this already present, it makes sense for me to spend some time in figuring out how I can modify convergencing parameters. Background: in real situations it always can happen that the canceller gets out of control and then convergences again (e.g. due to long pauses or near overload events). I'd use more conservative (slower) convergencing or even limits to internal state changes (analogy: limit of I-excursion of a tradidional pid-controller) when a "saved" SpeexEchoState is reused. -Rob On Fri, 27 May 2011 10:02:13 +0200, Simon Morlat <[email protected]> wrote: > 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 SpeexEchoState. >> >> Stuart >> >> On Thu, May 26, 2011 at 12:07 PM, Maris Engineering<[email protected]> >> wrote: >>>> 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 almost continuously had signal to stay adapted on. >>>> >>> This is the suboptimal approach... >>> >>>> 2011.05.25. 20:29 keltez?ssel, Stuart O. Anderson ?rta: >>>>> 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? >>> ... and this is considered to be the optimum approach (for e.g. >>> stationary >>> units). >>> >>> It is this latter which I asked in this mailing list about, some time >>> ago, >>> without reasonable answer. Stuart, do you know if it's possible to >>> retrieve the internal state variables in order to reassign them upon >>> startint a new VoIP-connection? >>> >>> -Rob >>> _______________________________________________ >>> Speex-dev mailing list >>> [email protected] >>> http://lists.xiph.org/mailman/listinfo/speex-dev >>> >>> >> _______________________________________________ >> Speex-dev mailing list >> [email protected] >> http://lists.xiph.org/mailman/listinfo/speex-dev >> > -- Maris Engineering Peter-Schlack-Straße 17 D-52372 Kreuzau phone +49 2422 904422 fax +49 3212 1073300 _______________________________________________ Speex-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/speex-dev