How can I tell when android AudioRecord read() method encounters an overflow?

Question

I am using android.media.AudioRecord to get raw audio input, and then I am processing this in real-time to display immediate feedback. I can adjust various processing parameters to change the quality of the feedback, with a corresponding change in processing time.

As I increase processing time, at some point AudioRecord starts to overflow and read() starts missing chunks of data. Besides a noticable change in the display, I get the following message in LogCat (I am using eclipse to debug): "E/AudioHardwareYamaha(2579): snd_pcm_readi read error -32"

How can my app find out about this error? It is not good enough to find out while debugging, I want the app to know when this happens so it can automatically adjust the parameters, to find a sweet spot where the quality is as high as possible but the overflows are gone or infrequent. I assume this sweet spot will be different on different hardware.

I have checked here and elsewhere, but the suggestions I have found fall short:

• Increasing the buffer size beyond some small multiple is not a solution, as it only defers an inevitable glitch (and adds latency to the feedback).

• I have seen a suggestion for putting reading and processing in separate threads. Basically this amounts to a wrapper for AudioRecord, adding a good deal of complexity and even more processing, just to do my own error detection. My app is basically done, and I don't really want to refactor everything if I can avoid it.

• Checking elapsed times against what is expected seems to be the most workable solution at this time, but it seems bizarre that I have to settle on such an indirect strategy to guess at what AudioRecord has done (and logged).

Is there a simple way for an app to capture the error information that is being logged?

Answer 1

Just to answer my own question in case someone stumbles on this...

I was not able to find a good solution, but I have been using a work-around. I ended up using the clock, rather than the audio input hardware. Since I know how big my input buffer is, and I know how many input samples are made per second, and I can find how fast my code is running from the system clock, I can calculate when an overflow SHOULD occur, and write my code around that.

Not exactly what I was hoping for, but it accomplished what I needed.