Android OpenSLES Buffer Starvation issue

Question

I am trying to work around the following issue in Android OpenSLES.

The OpenSLES Spec Says the following:

http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf - 8.12

When the player is in the SL_PLAYSTATE_PLAYING state, which is controlled by the SLPlayItf interface [see section 8.32], adding buffers will implicitly start playback. In the case of starvation due to insufficient buffers in the queue, the playing of audio data stops. The player remains in the SL_PLAYSTATE_PLAYING state. Upon queuing of additional buffers, the playing of audio data resumes. Note that starvation of queued buffers causes audible gaps in the audio data stream. In the case where the player is not in the playing state, addition of buffers does not start audio playback.

Alas once we get to android:

http://mobilepearls.com/labs/native-android-api/ndk/docs/opensles/index.html - Decode audio to PCM

Depending on the platform implementation, decoding may require resources that cannot be left idle. Therefore it is not recommended to starve the decoder by failing to provide a sufficient number of empty PCM buffers, e.g. by returning from the Android simple buffer queue callback without enqueueing another empty buffer. The result of decoder starvation is unspecified; the implementation may choose to either drop the decoded PCM data, pause the decoding process, or in severe cases terminate the decoder.

This non-spec behavior has completely stopped progress on my project and I'm lost as how best to work around it. Decoding the entire file to pcm in memory or on disk is not an option, I really need this to be a streaming solution. Any help on this would be massively appreciated

Answer 1

There doesnt seem to be a way around this issue. Other projects seem to use lower level apis (such as libstagefright) to do their decoding. That method does let you get at the data

[EDIT] There isn't a way around the starvation issue. Android just doesn't adhere to the spec. Basically you need to buffer into memory and make sure that you use pause and resume to decoding when you need to control the flow of the data.

This is a discussion on the subject in the ndk google group