Why does it take so long for Android's MediaPlayer to prepare some live streams for playback?

Question

I am finding big differences in the time it takes the Android MediaPlayer to prepare for live stream playback with different streams.

The hard data

I added logging between prepareAsync() and the onPrepared(MediaPlayer mp) callback and tested several streams a few times each. The times for each stream were very consistent (+/- one second), and here are the results:

1. MPR news stream: 27 seconds (http://newsstream1.publicradio.org:80/)
2. MPR classical music stream: 15 seconds (http://classicalstream1.publicradio.org:80/)
3. MPR The Current stream: 7 seconds (http://currentstream1.publicradio.org:80/)
4. PRI stream: 52 seconds (http://pri-ice.streamguys.biz/pri1)

The tests were performed on a Nexus S with Android 2.3.4 on a 3G connection (~1100 Kbps).

Playing non-streaming MP3 audio files is not an issue.

Here are snippets of how I am playing the streams:

Prepare MediaPlayer:

... mediaPlayer.setDataSource(playUrl); mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC); mediaPlayer.prepareAsync(); ... 

Then in onPrepared(MediaPlayer mp):

mediaPlayer.start(); 

Why does it take so long to prepare some streams but not others? The above data seems to suggest that it might be based on the amount of data that has been buffered and not the duration of the buffered audio content. Could this really be?

Update: I have tested live streaming on physical devices with Android 1.6, 2.2 and 2.3.4 and emulators with 1.6, 2.1, 2.2, 2.3.1 and 2.3.3. I am only seeing the long delay on 2.3.3 and 2.3.4. The older versions start playback within 5 seconds.

Answer 1

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:

1. MPR news stream: 27 seconds (http://newsstream1.publicradio.org:80/), 64 kbps
2. MPR classical music stream: 15 seconds (http://classicalstream1.publicradio.org:80/), 128 kbps
3. MPR The Current stream: 7 seconds (http://currentstream1.publicradio.org:80/), 128 kbps
4. 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.