For what it's worth, I've tried various ways to fix the "slide" 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'd be interested in hearing other folks' attempts at a solution.<div>
<br></div><div>For what it's worth, even when there's significant slide, if you combine the echo canceller with the echo suppressor, it works OK: I'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 "subconversation" going on in the background that makes it sound like you'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"><<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>></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>
> Hi,<br>
><br>
> I implemented a small patch that allows the internal convergence state<br>
> of the echo canceller to be saved in a file for later use, especially<br>
> after a process restart or machine reboot. This enables immediate echo<br>
> cancellation the second time the AEC is run.<br>
><br>
> Of course this works only if the acoustic environment of the device<br>
> doesn't change and if the soundcard latency is constant.<br>
</div>That'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>
> To use this feature, proceeed as this:<br>
> - use speex_echo_ctl() with SPEEX_ECHO_GET_BLOB to obtain a<br>
> SpeexEchoStateBlob, at the end of an audio session, when the echo<br>
> canceller is supposed to be converged.<br>
> - save the blob to a disk file for example, using<br>
> speex_echo_state_blob_get_data() and speex_echo_state_blob_get_size() to<br>
> retrieve the actual data<br>
><br>
> To restore the state later, after a reboot or a process restart, do the<br>
> following:<br>
> - read the data from the file where you previously save the blob's<br>
> contents<br>
> - instanciate a blob object from this data using<br>
> speex_echo_state_blob_new_from_memory()<br>
> - assign the blob to the echo canceller using speex_echo_ctl() with<br>
> SPEEX_ECHO_SET_BLOB, before the echo canceller starts processing data.<br>
><br>
> The way it works is that is saves the foreground weights of the echo<br>
> canceller filter. When restored, it is also restored in the background<br>
> filter. Some sanity checks on the configuration parameters ( frame size,<br>
> filter length, channels) are performed to verify that the restoration is<br>
> applicable to the current echo state object.<br>
> I wonder if there are parameters other than weights that should be saved<br>
> too. Feel free to comment, adapt, apply or reject.<br>
><br>
> On a side comment, I would like to congratulate the author(s) of the<br>
> Speex Echo Canceller, because it really works very well compared to<br>
> competition and provide good cancellation even in difficult situations.<br>
> The performance of the non-linear echo suppression with the<br>
> 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>