NDK SLES decode MP3 to PCM end criteria

[sbilkoloft]

Hi,

There have been lots of discussions here about how to decode sound asset files using an fd source and buffer queue sink to extract the PCM data. You just enqueue an empty buffer, register a callback and set the player's status to playing. The callback will be called with decoded data where you re-enqueue the buffer to get the next chunk and so on. There has been no talk about the last cycle.

1) Each time the callback is called, how do you know if there is still more data to be decoded? How can the callback decide if it should re-enqueue the buffer or signal another thread decoding is done?

2) In the last iteration where the callback is invoked, how will it know how much of the buffer is filled with decoded data? In all invocations (except the last) the buffer will be full (i.e., the size you pass to Enqueue). In the last iteration the buffer may be half full. How to know how much of it is full with decoded data?

The bigger picture of what I generally trying to do is this. I want to decode a bunch of sound effect files at load time into buffers, then at run time when I need the sound effects played, play them as decoded buffers from memory without having to load from assets which are encoded.

Help? Thoughts? Hints?

Thanks

[sbilkoloft]

So seems like the answer to #1 is this:

The end of stream is determined implicitly by the data source. At the end of stream a SL_PLAYEVENT_HEADATEND event is delivered. The Android simple buffer queue callback will no longer be called after all consumed data is decoded.

But what about #2? Does the buffer size have to be some magical number for things to work properly?

[sbilkoloft]

I seem to have figured it out. Apparently in the MP3 world there is a fixed 1152 (not 100% right - see fine print below for details) samples per frame. So I pass a buffer of size 1152 times samples size (in my case 2 bytes) to the decoder. I keep doing this until I get the had at end signal.

Fine print: so depending on the MPEG type it could be 1152 or some other magic number. Based on what I found most MP3s these days have 1152 samples per frame, but older ones have the other magic number. In order to deal with this properly, you'd have to get the first decoded frame, check the meta data, and from there on decide which magic number to use. Haven't done this yet. I prefer to just use 1152 and skip the MP3 that don't open :D.

[Don Turner]

Have you considered using the NDK Media API to do the extraction and decoding? You can use the methods found in the media/NdkMediaExtractor.h file for this. 

More info here: https://developer.android.com/ndk/reference/ndk_media_extractor_8h.html

[sbilkoloft .]

Hi Don,

Honestly I wasn't really sure that's what it did. I looked at the native codec sample and couldn't figure out if it'll do what I needed. Seems like these are the dark corners of the NDK with almost no documentation. That sample seems to use it's own looper implementation to utilize multiple threads to decode the media.

If you can confirm a high level overview of what needs to happen it'd be appreciated. Like with SLES I understand the thread model of the players and the sink & drain. To get native codec to work, I spawn some threads which sleep while the decoder is working and a main thread which block until all threads are done?

Cheers.

--
You received this message because you are subscribed to a topic in the Google Groups "android-ndk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-ndk/O7qHhmX5VzM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/ba03963a-e508-497b-9137-f7efb2e91493%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.