CODEWITHSUNDEEP
androidmp3signal-processingdecoding
Steven Pongidin
Steven Pongidin

Reputation: 153

Slow MP3 decoding on Android

I've been working on MP3 decoding in Android based from this tutorial

Somehow, it takes more than 1 minute to decode a 4:30 duration song which is totally unacceptable in my case. I've been trying to figure out what is the problem and looking for a way to improve the speed. Been searching over the internet for days and still couldn't figure out why because the resource is very limited. I think I'm totally stuck here since I couldn't get anything from research.

Can someone point out any information about processing MP3 file in Android? I am using Libmad to decode the MP3 file and port it to Android with NDK. Maybe someone can point out any alternatives for MP3 decoding. I appreciate any information about it, thank you very much.

Upvotes: 3

Views: 2385

Answers (1)

Caner
Caner

Reputation: 59148

All answers you seek for are already on the tutorial page.

As he explains in the article the time it takes seems to be normal:

I tested it with the song “Schism” by tool which is a 6:47min long song, encoded at 192kbps. The file weights in at 9.31mb, pretty big for an mp3 imo... Without any optimizations (thumb code, -O0, -DFPM_DEFAULT == standard fixed point math in libmad, no arm assembler optimized fp math) decoding the complete files takes 184 seconds on my Milestone.

Then he explains how he optimized it. You should follow the same steps:

Holy shit, batman! If i eliminate the buffer.get( samples ) call that gets down to 44 seconds! Incredible. Now i still thought that is way to slow so i started adding optimizations. The first thing i did was compiling to straight arm instead of thumb code. You can tell the NDK toolchain to do so by placing this in the Android.mk file:

LOCAL_ARM_MODE := arm

With this enabled decoding takes 36 seconds. The next thing i did was agressive optimization via -O3 as a CFLAG. That shaved off only 2 more seconds, so nothing to write home about. The last optimization is libmad specific. The config.h file i linked to above does not define the fixed point math mode libmad should use. Now, when you have a look at fixed.h of libmad you can see quiet some options for fixed point math there. There’s also a dedicated option for arm processors that uses some nice little arm assembler code to do the heavy lifting. You can enable this by passing -DFPM_ARM as a CFLAG. Now that did wonders! i’m now down to 20 seconds for decoding 407 seconds of mp3 encoded audio. That’s roughly 20x real-time which is totally ok with me. The song i chose is at the extreme end of the song length spectrum i will have to handle in my next audio game project. A song a user uses will be processed once and waiting for that 20 seconds is ok in my book.

And the most important part comes:

I’m afraid i won’t release the source of the ported audio framework as it’s a bit of a mess and would need some work to clean up.

And many people in the comments rant about the library and say that they gave it up in favor of libmpg123

Upvotes: 1

Related Questions