OpenSL ES PrefetchItf assert fails on new data after bufferqueue was underflowed

[sanne.ra...@gmail.com]

Hai,

I'm implementing an android hostapi for the portaudio library (https://github.com/Gundersanne/portaudio_opensles/tree/portaudio_opensles_ticket_154/src/hostapi/opensles).

Portaudio expects the different hostapi's (in this case android/OpenSL ES) to supply the user with some information about underflow/overflow. So the PrefetchStatusItf seems suited.

When the buffer underflows, and the queue was empty, and new data was queued; this assert is executed:

void android_audioPlayer_bufferQueue_onRefilled_l(CAudioPlayer *ap) {
...
assert(SL_PREFETCHSTATUS_UNDERFLOW == ap->mPrefetchStatus.mStatus);
...

and fails. Aborting the entire stream. As I understand it correctly this assert checks if the prefetchstatus was set to underflow when the buffer was allowed to empty and the user wants to enqueue new data.

This of course has a higher chance of happening the smaller the buffer sizes are or if the AUDIO_OUTPUT_FLAG_FAST wasn't set, or when reducing the number of buffers.

Now the opensles specification states that if you don't enqueue any buffers (and thus underflow and then completely empty), the audio playback/recording should simply stop; and resume when new buffers are enqueued.

It's perhaps noteworthy that I haven't encountered this when that pause between the buffer being completely empty and the enqueueing of new data was quite long (50/100/200/300 ms). It's only when in a thread (that's continuously supplying the bufferqueue with new data) a tiny underflow/empty occurs, that this happens.

I would like to notify the user that an underflow occurred, without killing the entire stream. That way the user can up the buffer size if this happens too often for their liking.

[sanne.ra...@gmail.com]

* my mistake, this also happens on long pauses.

So I suppose my question is, can I use this interface, while still having pauses between enqueueing of data and allowing it to completely empty.

Op maandag 20 maart 2017 02:33:40 UTC+1 schreef sanne.ra...@gmail.com: