Android MediaPlayer.prepare() takes very long time for API > 2.3 (Is it because of StageFright?)

Question

(This question is partly related to Why does it take so long for Android's MediaPlayer to prepare some live streams for playback?)

I tried to play the following audio stream on different devices with android MediaPlayer: http://newsstream1.publicradio.org.

I finally noticed there is a huge difference of duration for the prepare() method between devices <= 2.2 (it takes less than 1 second) and devices > 2.2 (it can take up to 30 seconds...)

Is it related to the underlying audio framework ? (OpenCore VS StageFright)

Has someone already experienced it ? And do you know any better solution to read mp3 streams with StageFright media player ?

Answer 1

Well, after digging around I come up to the conclusion that the loading time depends on the buffer size of the MediaPlayer (which is somehow hardcoded in the firmware) and that there is nothing that can be done to change it.

Answer 2

It does appear that it is buffering a fixed amount of data rather than a fixed amount of time. For anyone who doesn't know the bitrates of various types of NPR streams off the top of their head, the data looks like:

MPR news stream: 27 seconds (http://newsstream1.publicradio.org:80/), 64 kbps MPR classical music stream: 15 seconds (http://classicalstream1.publicradio.org:80/), 128 kbps MPR The Current stream: 7 seconds (http://currentstream1.publicradio.org:80/), 128 kbps PRI stream: 52 seconds (http://pri-ice.streamguys.biz/pri1), 32 kbps Apart from the discrepancy between the two 128 kbps streams, there is a very good correlation between bitrate and buffering duration.

In any case, Android is open-source, so you could always look at what it's doing. Unfortunately, prepareAsync() and prepare() are native methods, and it appears that buffer-related events are dispatched from a native process as well.

Have you tried attaching an OnBufferingUpdateListener to the MediaPlayer to get finer-grained updates about the buffer-state? It might be interesting to compare the rate at which the events are delivered and by what percentage the buffer fills on each event across the different streams. You can cross-reference that against the stream bitrates, and if 4 seconds of buffering at 32 kbps fills the buffer the same percentage as 1 second of buffering at 128 kbps then I think you will have found your answer.

Derived From here.

Answer 3

It shouldn't be taking that long, but the MediaPlayer API has an asyncPrepare() method that they recommend you use to keep your application running smoothly.