Android: AudioRecord Class Problem: Callback is never called

Question

My Android Java Application needs to record audio data into the RAM and process it. This is why I use the class \"AudioRecord\" and not the \"MediaRecorder\" (records only t

Answer 1

Now I implemented the recording using the "OnRecordPositionUpdateListener". This looks very promising and the right way to do it according the SDK Docs. Everything seems to work (opening the audio device, read()ing the data etc.) but the Listner is never called.

Does anybody know why?

I found that the OnRecordPositionUpdateListener is ignored until you do your first .read().

In other words, I found that if I set up everything per the docs, my the Listener never got called. However, if I first called a .read() just after doing my initial .start() then the Listener would get called -- provided I did a .read() every time the Listener was called.

In other words, it almost seems like the Listener event is only good for once per .read() or some such.

I also found that if I requested any less than buffSize/2 samples to be read, that the Listener would not be called. So it seems that the listener is only called AFTER a .read() of at least half of the buffer size. To keep using the Listener callback, one must call read each time the listener is run. (In other words, put the call to read in the Listener code.)

However, the listener seems to be called at a time when the data isn't ready yet, causing blocking.

Also, if your notification period or time are greater than half of your bufferSize they will never get called, it seems.

UPDATE:

As I continue to dig deeper, I have found that the callback seems to ONLY be called when a .read() finishes......!

I don't know if that's a bug or a feature. My initial thought would be that I want a callback when it's time to read. But maybe the android developers had the idea the other way around, where you'd just put a while(1){xxxx.read(...)} in a thread by itself, and to save you from having to keep track of each time read() finished, the callback can essentially tell you when a read has finished.

Oh. Maybe it just dawned on me. And I think others have pointed this out before me here but it didn't sink in: The position or period callback must operate on bytes that have been read already...

I guess maybe I'm stuck with using threads.

In this style, one would have a thread continuously calling read() as soon as it returned, since read is blocking and patiently waits for enough data to return.

Then, independently, the callback would call your specified function every x number of samples.