Google Cast slow for some streams

Question

I have an Android app which plays live streams from web (mostly icecast) via Google Cast. Everything worked fine and fast, but now it takes much longer time for some streams to start (make sound). This may be somehow related to the Chromecast firmware upgrade as my Chromecast device got updated to the latest version (1.32.124602) recently.

This is how I play stream via Cast:

MediaMetadata metadata = new MediaMetadata(MediaMetadata.MEDIA_TYPE_GENERIC);
metadata.putString(MediaMetadata.KEY_TITLE, "My title");
metadata.putString(MediaMetadata.KEY_SUBTITLE, "My subtitle");
metadata.addImage(new WebImage(myImageUri);
MediaInfo mediaInfo = new MediaInfo.Builder(streamUrl)
        .setStreamType(MediaInfo.STREAM_TYPE_LIVE)
        .setContentType("audio/mpeg")
        .setMetadata(metadata)
        .build();
MediaLoadOptions options = new MediaLoadOptions.Builder()
       .setAutoplay(true)
       .setPlayPosition(0)
       .build();
sessionManager.getCurrentCastSession().getRemoteMediaClient().load(mediaInfo, options);

Strange thing is, that some streams are pretty fast and others not:

1. http://stream.funradio.sk:8000/dance128.mp3 - This makes sound after more than 20 seconds
2. http://stream.expres.sk:8000/128.mp3 - This makes sound in 1 second

I also noticed that ResultCallback of the load() function is triggered almost instantly for the second stream, while first one takes about 3 seconds.

I appreciate any help or idea how to fix this.

Answer 1

The second link has a larger buffer to flush to you.

This graph shows throughput. The first squiggle is when I tested the first URL on stream.funradio.sk:8000. The second squiggle is when I tested the second URL on stream.expres.sk:8000.

You'll notice that in both, there is a burst of data right at the beginning of the connection. These are designed to fill the player buffers as fast as possible, to start playback immediately. You'll also notice that the second stream has a lot more of this at the start of the connection. This is because it had a buffer of audio data ready to go.

The buffer size is configurable per-stream. The folks that configured the second stream thought to increase this buffer, which enables fast starts for listeners, which has been found to be critically important in retaining listeners. The only real tradeoff here is latency. That second stream has effectively pre-recorded several seconds of audio to send to new clients. For most internet radio stations, this latency isn't a problem at all. It's far better to have that stream start quickly, and be more reliable for listeners with spotty connections.

I appreciate any help or idea how to fix this.

Short of proxying the streams, there isn't much you can do about it. Android devices and Chromecast are particularly picky about MP3 streams and require a lot of data to synchronize to them.

Additionally, the algorithm Chrome is using to determine if the buffer is sufficiently full to play without stalling doesn't know you're giving it a radio stream, and sees the drop in rate and buffers a bit more before starting. This issue can be worked around by coding up your own player entirely that buffers the data and then passes it off to a decoder, rather than just giving the underlying system a URL. On the web, this can be done with Media Source Extensions. For Android, I don't have much experience there.