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

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.

Switch MediaPlayer by FFmpegMediaPlayer works much betther than the MediaPlayer if you want to test your streams you can do it through the demo that they have.

I have recently debugged this same issue with a streaming audio provider. The issue is related to stagefright and streaming sources 32kbps and lower. We stepped through the same streaming measuring the response time at 24, 32, 48, 64 and 128 kbps.

• 24 -> 46 seconds to start streaming
• 32 -> 24 seconds to start streaming
• 48 -> 2 seconds to start streaming
• 64 -> 2 seconds to start streaming
• 128 -> 2 seconds to start streaming

This is from a consistent, wireless connection averaged over 10 attempts at each bit rate. The key, as Travis pointed out, was that stagefright could not figure out how long to buffer the audio. Sometimes i would see a message 'error: 1,-21492389' or so, which seemed to crash the stagefright player silently. I tried to track this down and eventually came to the conclusion that the very slow streams (sub 24 kbps) seemed to cause a buffer overflow because they would buffer until the device ran out of space for the audio stream.

I wanted to add that OnBufferingUpdateListener did not fire at all for me during this entire test. I don't know what it is there for. I think the only way you can tell how loading is going is to proxy the loading, in a similar fashion to the NPR app mentioned above.