> 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
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 <mail at maris-ee.eu> 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 > Speex-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >
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<mail at maris-ee.eu> 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 >> Speex-dev at xiph.org >> http://lists.xiph.org/mailman/listinfo/speex-dev >> >> > _______________________________________________ > Speex-dev mailing list > Speex-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev >