OpenSL format of decompressed PCM

[Gerard Meier]

We are decompressing an MP3 into PCM format using AndroidSimpleBufferQueue.

Following the documentation we noticed that the PCM format is left up to the 

device itself. In our particular use-case we work with mono MP3s - but on some 

devices OpenSL decompresses them into stereo PCM. Playing stereo PCM as if it's 

mono doesn't quite work (it sounds like slow motion). In an effort to detect 

the number of channels in the output PCM, we are using the MetaData interface; 

unfortunately on our test device this still returns "1" for the amount of 

channels, even though it outputs a stereo PCM. 

As a workaround we decompress the MP3 and compare the resulting byte-size with 

an expected byte-size and derive our own mono signal from the PCM when the size 

exceeds the expected rate. This works for the time being; though it is far from robust.

We attempted to query for metadata during different stages (after initial 

enqueue, during the re-queue callbacks and post decompression), all at no 

avail. Interestingly enough, the other metadata fields appear to be correct 

(sample rate / bits per sample / etc).

Is it a known issue for metadata to be incorrect? Any insight into solutions 

or better work-arounds are much appreciated. (API 14/NDK-r9c)

Gerard

[Glenn Kasten]

Yes, that is surprising.  Sounds like we need a better compatibility

testing in this area.

Can you please share which device(s) and platform version(s) that you have tested

work as expected (that is, they decode to mono PCM for mono MP3 input),

and which device(s) and platform version(s) decode to stereo PCM for mono MP3 input?

p.s. for API levels that support it, you might want to also try the Java MediaCodec API.