For what it&#39;s worth, I&#39;ve tried various ways to fix the &quot;slide&quot; that happens when your microphone gives you (say) 20.5 ms or 19.5 ms worth of samples every 20 ms. Â Unfortunately, all of my attempted solutions have ended up making the echo cancellation problem worse. Â For instance, I would watch the microphone stream, and if, over time, I saw that it was sending (say) 640 bytes bytes every 19.5 ms instead of every 20 ms, I would buffer and downsample the stream so I could send 640 bytes to the echo canceller every 20 ms instead of 640 bytes every 19.5 ms. Â But it never seemed to work. Â Obviously the buffering screws with the AEC, but my assumption had been that so long as the buffering was consistent, the AEC would adjust. Â But perhaps I was just doing something wrong. Â I&#39;d be interested in hearing other folks&#39; attempts at a solution.<div>
<br></div><div>For what it&#39;s worth, even when there&#39;s significant slide, if you combine the echo canceller with the echo suppressor, it works OK: I&#39;m getting something like 90% of the echo removed in my testing. Â The problem really becomes noticeable when there are more than two or three people on the call: all the little bits of remaining echo combine to create a really nasty &quot;subconversation&quot; going on in the background that makes it sound like you&#39;re all in a very noisy coffee shop.<br clear="all">
<br>Ken Smith<br>Cell: 425-443-2359<br>Email: <a href="mailto:ken@alanta.com" target="_blank">ken@alanta.com</a><br>Blog: <a href="http://blog.wouldbetheologian.com/" target="_blank">http://blog.wouldbetheologian.com/</a><br>

<br><br><div class="gmail_quote">On Mon, Apr 4, 2011 at 5:08 AM, Steve Underwood <span dir="ltr">&lt;<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 04/04/2011 06:58 PM, Simon Morlat wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I implemented a small patch that allows the internal convergence state<br>
&gt; of the echo canceller to be saved in a file for later use, especially<br>
&gt; after a process restart or machine reboot. This enables immediate echo<br>
&gt; cancellation the second time the AEC is run.<br>
&gt;<br>
&gt; Of course this works only if the acoustic environment of the device<br>
&gt; doesn&#39;t change and if the soundcard latency is constant.<br>
</div>That&#39;s probably a fair assumption for a desktop machine, but totally<br>
bogus for a notebook. Is there a clear way to tell the difference, and<br>
make a judgement as to whether this feature should be enabled.<br>
<div><div></div><div class="h5"><br>
&gt; To use this feature, proceeed as this:<br>
&gt; Â  - use speex_echo_ctl() with SPEEX_ECHO_GET_BLOB to obtain a<br>
&gt; SpeexEchoStateBlob, at the end of an audio session, when the echo<br>
&gt; canceller is supposed to be converged.<br>
&gt; Â  - save the blob to a disk file for example, using<br>
&gt; speex_echo_state_blob_get_data() and speex_echo_state_blob_get_size() to<br>
&gt; retrieve the actual data<br>
&gt;<br>
&gt; To restore the state later, after a reboot or a process restart, do the<br>
&gt; following:<br>
&gt; Â  - read the data from the file where you previously save the blob&#39;s<br>
&gt; contents<br>
&gt; Â  - instanciate a blob object from this data using<br>
&gt; speex_echo_state_blob_new_from_memory()<br>
&gt; Â  - assign the blob to the echo canceller using speex_echo_ctl() with<br>
&gt; SPEEX_ECHO_SET_BLOB, before the echo canceller starts processing data.<br>
&gt;<br>
&gt; The way it works is that is saves the foreground weights of the echo<br>
&gt; canceller filter. When restored, it is also restored in the background<br>
&gt; filter. Some sanity checks on the configuration parameters ( frame size,<br>
&gt; filter length, channels) are performed to verify that the restoration is<br>
&gt; applicable to the current echo state object.<br>
&gt; I wonder if there are parameters other than weights that should be saved<br>
&gt; too. Feel free to comment, adapt, apply or reject.<br>
&gt;<br>
&gt; On a side comment, I would like to congratulate the author(s) of the<br>
&gt; Speex Echo Canceller, because it really works very well compared to<br>
&gt; competition and provide good cancellation even in difficult situations.<br>
&gt; The performance of the non-linear echo suppression with the<br>
&gt; speex_preprocess() api is really amazing.<br>
</div></div>It works well if the sound card has synchronised mic and speaker<br>
sampling, and is horrible otherwise. So, its great on Macs, and pot luck<br>
on PCs. Perhaps the canceller should detect one sampling rate sliding<br>
against the other, and talk alternate action?<br>
<br>
Steve<br>
_______________________________________________<br>
Speex-dev mailing list<br>
<a href="mailto:Speex-dev@xiph.org">Speex-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/speex-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/speex-dev</a><br>
</blockquote></div><br></div>