OpenSL - Poor Seeking with Audio Player Object

Question

I'm writing an Android application that needs to be able to seek to specific points in a large mp3 audio file (~90minutes) with good accuracy.

Currently, I'm using an OpenSL approach with an audio player object with a URI data source that specifies the mp3 file and MIME information.

To test this out, I use the SLSeekITF interface on the player to seek to specific points (specified in milliseconds). However, I find that the seeking performance is poor and inconsistent. Often the audio is 1-10 seconds off from where it should be. Sometimes ahead, sometimes behind. Performance is a little bit better using shorter mp3 files, but nowhere near close enough.

The Seek modes ("accurate" and "fast") don't seem to make any difference on SLSeekITF.

On other platforms, I can get the seek position to be very accurate < 50msec which is barely noticeable, so I know this is possible.

-Does anyone know how to get better accuracy out of the OpenSL audio player? -Are there known issues with this implementation? -Are there other mp3 decoders available that offer better performance?

Thanks

Answer 1

I also posted this question on the Google NDK Group: https://groups.google.com/forum/#!topic/android-ndk/rzVr3A0DjBs

While I never got an official answer from anyone at Google, the feedback I received seem to indicate that Media Player and/or playing audio from a URI with OpenSL ES is known to be buggy.

I ended up solving this problem by using a 3rd party mp3 decoder with seeking ability and a Buffer Queue Audio Player object in OpenSL ES to playback the audio samples.

Hardly easy to do, but it works.