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.

Answer 2

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.

Answer 3

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.

Answer 4

If you're streaming from Icecast, take a look at the burst-size setting:

The burst size is the amount of data (in bytes) to burst to a client at connection time. Like burst-on-connect, this is to quickly fill the pre-buffer used by media players. The default is 64 kbytes which is a typical size used by most clients so changing it is not usually required. This setting applies to all mountpoints unless overridden in the mount settings. Ensure that this value is smaller than queue-size, if necessary increase queue-size to be larger than your desired burst-size. Failure to do so might result in aborted listener client connection attempts, due to initial burst leading to the connection already exceeding the queue-size limit.

I increased the burst-size to 131072 on my server, and now my Android app based on MediaPlayer plays streams without much delay.

Answer 5

I've tried this with 10 datapoints, three fast, 7 slow. It's consistent, that is a fast stream is fast and a slow one is always slow.

I think it's related to the server delivered 'content-length,' Android doesn't know how much to buffer if the content-length isn't properly specified.

Could be wrong, didn't go as far as wiresharking.

Answer 6

When I had this problem I decided to test if stream is available before opening the player. If you make the user to wait for a long time and the music will start it ok (it's not, but let's say it is ok). The worst case scenario is to make him wait for a long time and the music will never start! So, we have 2 situations:

• The live streaming scenario, like a radio station.
• The recorded mp3 file which is available online.

At the radio scenario we could check if the port is accepting connections (open/close state). If it is open prepare the player for the music, else do not prepare it at all.

public static boolean isLiveStreamingAvailable() {
        SocketAddress sockaddr = new InetSocketAddress(STREAMING_HOST, STREAMING_PORT);
        // Create your socket
        Socket socket = new Socket();
        boolean online = true;
        // Connect with 10 s timeout
        try {
            socket.connect(sockaddr, 10000);
        } catch (SocketTimeoutException stex) {
            // treating timeout errors separately from other io exceptions
            // may make sense
            return false;
        } catch (IOException iOException) {
            return false;
        } finally {
            // As the close() operation can also throw an IOException
            // it must caught here
            try {
                socket.close();
            } catch (IOException ex) {
                // feel free to do something moderately useful here, eg log the event
            }

        }
        return true;
    }

At the mp3 file scenario the things are a little bit different. You should check for the response code which follows after the http request.

public static boolean isRecordedStreamingAvailable() {
        try {
            HttpURLConnection.setFollowRedirects(false);
            // note : you may also need
            //        HttpURLConnection.setInstanceFollowRedirects(false)
            HttpURLConnection con =
                    (HttpURLConnection) new URL(RECORDED_URL).openConnection();
            con.setRequestMethod("HEAD");
            return (con.getResponseCode() == HttpURLConnection.HTTP_OK);
        }
        catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }