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.