[Speex-dev] Speex-dev Digest, Vol 115, Issue 2
j.equalizer at gmail.com
Fri Feb 7 01:31:00 PST 2014
echo_diagnostic.m can produce an echo canceled file along with the
possible warning messages.
Can it cancel the echo properly?
It may announce the "Drift estimate is ..." message if the recorded
sound contains not only echo but also other sound like a near-end
speech. In other cases, it may truly indicate a mismatch of the
On Thu, Feb 6, 2014 at 4:00 AM, <speex-dev-request at xiph.org> wrote:
> Send Speex-dev mailing list submissions to
> speex-dev at xiph.org
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> speex-dev-request at xiph.org
> You can reach the person managing the list at
> speex-dev-owner at xiph.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Speex-dev digest..."
> Today's Topics:
> 1. Struggling with AEC and OpenSL (Rhett Aultman)
> Message: 1
> Date: Tue, 4 Feb 2014 13:30:43 -0800
> From: Rhett Aultman <roadriverrail at gmail.com>
> Subject: [Speex-dev] Struggling with AEC and OpenSL
> To: speex-dev at xiph.org
> <CAK8xaMkfpH_baaZ8pfJZFkwDHmWU7rbyVmviVNRRNBGfPJOPZg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> Hi, Speex devs,
> I apologize in advance if this is not the proper venue for this question,
> but I had seen in the archives that other threads of this nature had been
> In brief, I'm trying to get AEC working on a simple Android NDK app. It's
> a basic "play from a file, record from the mic to file" loopback test. I'm
> using OpenSL ES. I establish a player and a recorder at a 16kHz sampling
> rate. OpenSL generally works by presenting buffers to players and
> recorders, and you get called back when the buffer has been used. Both the
> player and the recorder are operating with only one buffer, and in the
> player and recorder callbacks from OpenSL, I make calls to Speex AEC.
> Everything is working in a frame size of 160 samples (10ms of audio). The
> source file is mono.
> Obviously, I'm writing because I'm not able to ever cancel the echo. I
> compiled Speex to dump the internal state of the echo canceler, and I found
> a copy of echo_diagnostic.m online which works. Initially, echo_diagnostic
> was telling me I had a far-end-to-near-end delay of 2700-3000 samples,
> varying from test to test. So, I developed a buffering system to delay the
> calls to speex_echo_playback(). With approximately 16 frames worth of
> delay buffer, I have been able to drive the far-end-to-near-end delay down
> to nearly 400 samples. Now, however, echo_diagnostic is warning me about
> clock drift. It gives me messages like this:
> "Drift estimate is -0.254065% (-160 samples)
> Your clock is drifting! No way the AEC will be able to do anything with
> that. Most likely, you're doing capture and playback from two different
> I would think it's highly unlikely for a Google Nexus 7 tablet to have two
> different sound cards for its speaker and its body mic, so I doubt that
> this is the issue. I don't really have a good grasp of how the drift gets
> measured and what, if anything, my own code could be doing to introduce it.
> I'm feeling a bit frustrated because, while I understand what's
> conceptually going on in AEC, I can't seem to make a simple echo test to
> demonstrate it in implementation. I'd love any advice you'd be willing to
> As an additional note, I based the native code for my test app off of the
> code found here:
> I'm not sure that code is right, either, because I have tried it out and
> hear echo there, and echo_diagnostic measured the far-end-to-near-end delay
> as -319 samples, despite the author's claims that the code works great and
> I just need to adjust the tail length.
> Thanks in advance for any advice any of you can offer me.
> Rhett Aultman | http://about.me/rhettaultman
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20140204/ed41ae80/attachment.html
> Speex-dev mailing list
> Speex-dev at xiph.org
> End of Speex-dev Digest, Vol 115, Issue 2
More information about the Speex-dev