Very slow buffering in Android

S

seb303

New Member
Hi,

For our radio application, we need to support the HTML5 audio tag playing on Android devices (Chrome browser). Unfortunately, when the stream from our InternetRadio Icecast server is played, it takes about 20 seconds before the sound starts. This is so long that most users think it's not working at all.

It is a fairly low rate stream (64kpbs), but even so. When testing some 56kbps Shoutcast streams, these start playing in about 7-8 seconds.

There is an Icecast setting: burst-on-connect (and also burst-size) which should help this problem, but I don't see any way to configure this from the admin interface. Can you help?

Thanks,
Seb
 
Support

Support

Level 1 Support
Staff member
Hi Seb,

We can enable the raw config for your Icecast server so that you can set this. What's your account username please?
 
Support

Support

Level 1 Support
Staff member
Thank you.

We have allowed you permission to edit your raw configuration file.

Please note that you will need to restart your server for the changes to take effect before you edit this.
 
S

seb303

New Member
Hi,

For some reason, none of the changes I am making to the IceCast config file are sticking. I edit the file, and save it, but when I click back to it, the changes are gone.

I can see the POST request appears to work ok...

POST to
https://control.internet-radio.com:2199/client/index.php
conf=<config data>&page=confeditor&setconf=undefined%3Aserver
RESPONSE:
{"status":"success"}

Not sure if setconf= has an invalid value though???
Or perhaps there is a file permissions problem on the server?

Seb
 
Last edited:
More Support

More Support

Level 2 Support
Staff member
Apologies. Its appears there's a bug in CentovaCast. I have submitted a support ticket. In the mean time I can edit the config file for you although it appears the burst on connect is already enabled with 64k as the default :

Code: 
    <!-- If enabled, this will provide a burst of data when a client
            first connects, thereby significantly reducing the startup
            time for listeners that do substantial buffering. However,
            it also significantly increases latency between the source
            client and listening client.  For low-latency setups, you
            might want to disable this. -->
           <burst-on-connect>1</burst-on-connect>
    <!-- same as burst-on-connect, but this allows for being more
            specific on how much to burst. Most people won't need to
            change from the default 64k. Applies to all mountpoints  -->
           <burst-size>65535</burst-size>

Just let me know what custom config you would like.

Its odd that there's such a delay for you. We run an HTML5 player in the main website directory and when testing with our Android (Lollipop)/Chrome(43.0) device we get :

WiFi : 128 kbps / Icecast = 4-5s.
3G : 128 kbps / Icecast = 7-8s.

We're using jPlayer on the site as our HTML5 player.
 
S

seb303

New Member
I did notice on your website that the buffering is quicker. I think this may be to do with the fact that the player is already initialised before connecting to the stream, since you share a player for multiple play buttons.

We're using the mediaelement HTML5 player on our website, but for testing purposes I've been using a simple html <audio> tag. Shoutcast is definitely quicker to start than Icecast. You can try the test page here:
http://lifeupgrade.tv/test.php

The test page has 2 different bitrate shoutcast streams + the icecast stream you mentioned + our stream (which may or may not be running depending when you try it). For a fair comparison, reload the page before trying each player.

What I'm seeing (over WiFi) is that the shoutcast streams take about 5 seconds to start, whereas the Icecast streams take 10 to 20 seconds.

With the Icecast steams there's a "stalled" event firing at about 8 seconds which makes me think the burst-size is too small. I believe Shoutcast uses about 1MB of queue/buffer (although I'm not sure how much of this is bursted to the client on connect). Certainly the stream delay is a bit longer with Shoutcast which does suggest that the initial burst is larger.

I also think that Android Chrome is loading the stream multiple times (looks like this in the server log files anyway). Perhaps once to load the meta data, and then again to play the audio. So this is likely adding to the delay.

As an experiment, can we try the following changes please:
<queue-size>204800</queue-size>
<burst-size>131071</burst-size>
<mp3-metadata-interval>4096</mp3-metadata-interval>
This last line needs to go within the <mount ....> sections. Currently it will be using the hardcoded server default value - I'm not sure what this is, but 4K seems reasonable to avoid unnecessary delays while Android Chrome waits for the meta data.

We have an important live broadcast on Sunday evening (9pm UK time), so hopefully we can do this experiment in plenty of time before then. If not, it may be better to wait until Monday just in case it causes unforeseen problems.

Thanks,
Seb

Edit: I just added a couple more shoutcast streams to the test page, as the original 2 (SomaFM) weren't coming from your servers, so perhaps not a fair comparison. The timing does seem to be variable, but in general the Icecast is definitely worse.
 
Last edited:
S

seb303

New Member
Thinking about it, the mp3-metadata-interval parameter is probably only relevant for clients sending an Icy-Metadata header (i.e. not for HTML5 audio). So please don't bother adding this to the config file. Let's just try with the larger burst size for now.
 
More Support

More Support

Level 2 Support
Staff member
Your test page really makes things easy to see. Thanks for posting it. Yes we do see an issue too. Even on WiFi the icecast server takes 8-9 seconds to play which is quite a long time! Shoutcast plays in 3-4 seconds.

I think both your assumptions are correct. From what I remember Shoutcast does have that 1MB buffer which is why there is a delay and this is all burst on connect afaik.

I've made the changes you requested just now (ignoring the mp3-metadata-interval parameter). I didn't want to do it over the weekend in case there was any issues.

Very interested to know your results :)

I'm still in communication with Centova over the raw config save error and will let you when this is resolved. In the meantime we are happy to make any changes for you provided you don't mind the delay.
 
S

seb303

New Member
Thanks for the config change. I'll give it a try a bit later. Do you think it would be worth commenting out the first queue-size value (near the top of the limits section)? I'm not sure how Icecast behaves if you specify a parameter multiple times.
 
S

seb303

New Member
Seems to be improved with the new settings, but still not as smooth as with Shoutcast.

It starts playing quicker now, but has a tendency to stop after about 1 second, and then have a further 4-5 second delay before it starts again.

Can we try a queue/burst size similar to Shoutcast, to eliminate any other potential differences between the servers. Then we can work backwards from there to try and minimise the stream delay as much as possible. Hopefully Centova will have a fix for the config edit bug soon so we can avoid too much back and forth.

<queue-size>1048576</queue-size>
<burst-size>943718</burst-size>

Thanks,
Seb
 
More Support

More Support

Level 2 Support
Staff member
Interesting. I've changed the settings for you. Restart the server for them to take effect. Lets see what happens now.
 
S

seb303

New Member
Seems much better now with the larger buffer. At least as fast as the Shoutcast stations, if not slightly faster. I don't have another Icecast stream to compare against as the one you mentioned has gone offline now. If you have an example of another Icecast stream let me know and I'll add it to the test page.... 64kpbs would be ideal for a direct comparison.

I'm inclined to wait for Centova to fix the config edit bug before doing further testing - to try and reduce the latency without compromising the buffering speed. Did they give any indication how long it might take to fix the bug and release the update?

Seb
 
More Support

More Support

Level 2 Support
Staff member
Excellent. Good to know. There seems to be a trade off between latency and play start time.

Here's a few more Icecast 2 servers to test against :

http://uk2.internet-radio.com:30163/
http://uk3.internet-radio.com:8077/
http://uk4.internet-radio.com:10936/

Centova are notoriously slow at reacting to bug fixes and I imagine it's going to be weeks if not months before there's a fix shipped. Last week they released the 3.2.1 update so the next one won't be for a while I'm afraid. I have recently discovered that admins (and i think resellers) can modify both those settings from the control panel without the need for raw config editing. Would you like me to set you up a reseller account (containing only your server) so you can see if you can get access to them that way ?
 
S

seb303

New Member
More Support said:
Excellent. Good to know. There seems to be a trade off between latency and play start time.
Click to expand...

Well, at least for Android there is anyway. Other players I've tried seem to need a much smaller buffer to get started.

If latency isn't an issue, then a bigger burst is always going to be better as it also provides more resilience against temporary network congestion. Unfortunately in our case we are running live, semi-interactive broadcasts, sometimes with phone-ins. This is why we chose to use Icecast to get the lower latency. Anyway, I will have a play and see if I can find a happy medium. I'll report back the settings that I find work best.


More Support said:
Here's a few more Icecast 2 servers to test against :

http://uk2.internet-radio.com:30163/
http://uk3.internet-radio.com:8077/
http://uk4.internet-radio.com:10936/
Click to expand...

I've added these to the test page if you want to try it. Icecast streams with default settings definitely do not work well with Android, and it's worse with lower bitrate streams (which is understandable as the client buffer will fill more slowly once the burst is exhausted).

More Support said:
Centova are notoriously slow at reacting to bug fixes and I imagine it's going to be weeks if not months before there's a fix shipped. Last week they released the 3.2.1 update so the next one won't be for a while I'm afraid. I have recently discovered that admins (and i think resellers) can modify both those settings from the control panel without the need for raw config editing. Would you like me to set you up a reseller account (containing only your server) so you can see if you can get access to them that way ?
Click to expand...

Yes please, that would be good. Could you also leave the Raw Config enabled as well, that way I can view/check the actual config file that the control panel is generating.

Many thanks for all your help with this.
 
More Support

More Support

Level 2 Support
Staff member
Bah! Just set it all up and logged in to test it and unfortunately the features are for admins only and not resellers. I also checked if the raw config setting worked for resellers or admins on the off chance and it doesn't either. Ohh well, we tried.

I'm still happy to make changes for you if you would like to continue testing. Hopefully Centova will be quicker on the raw config issue.
 
You must log in or register to reply here.
Top