<div dir="ltr">Hi, Speex devs,<div><br></div><div>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 discussed.</div><div><br>
</div><div>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.</div>
<div><br></div><div>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:</div>
<div><br></div><div><div>"Drift estimate is -0.254065% (-160 samples)</div><div>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 cards."</div>
</div><div><br></div><div>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.</div>
<div><br></div><div>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 offer.</div>
<div><br></div><div>As an additional note, I based the native code for my test app off of the code found here:</div><div><a href="http://yltechblog.blogspot.com/2012/08/speex-aec-with-android.html">http://yltechblog.blogspot.com/2012/08/speex-aec-with-android.html</a><br>
</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks in advance for any advice any of you can offer me.</div><div><br></div><div>Regards,</div><div>Rhett</div><div><div><br></div>-- <br><div>Rhett Aultman | <a href="http://about.me/rhettaultman" target="_blank">http://about.me/rhettaultman</a></div>
</div></div>