Minicaster: Flash Icecast2 and Shoutcast Players

How Minicaster works

Server software such as Icecast and Shoutcast use a concept called 'client pull webcasting' (CPW). Normally to supply a continual stream of music for a web radio station or live feed, content creators will use professional streaming servers such as Adobe Flash Media Server 2. These send the audio data in a series of tiny chunks that are thrown away by the client as soon as they're played - which makes it more secure and avoids filling the listener's computer with megabytes of data. Professional streaming servers cost a lot of money, and for the amateur market Icecast and Shoutcast provide a cheerful low-tech solution - but CPW is not streaming. We know both systems use the word 'stream' a lot in their documentation, but a stream is something with tiny chunks and some intelligence at the server end to 'negotiate' the data being sent. Instead of streaming the data, CPW servers just send out a single MP3 file. A huge MP3 file. In some cases if your webcast is running 24/7, it's an MP3 file of infinite size! The server limits the download speed so (if it all works properly) there's just enough data downloaded per second to keep up with the playback. All this data is delivered by HTTP - normal 'web' protocols - but the problem is what to do with all this data when you're listening!

Plugins for OS-level players like Winamp throw away the data every so often to avoid clogging your computer's memory - but Flash Player doesn't understand how to do this. When Macromedia was developing the sound engine for Flash Player many years ago, they didn't include methods to cope with very big files - people who wanted never-ending music went out and bought a streaming server like AFMS! Flash Player understands 'regular' MP3 files - a few megabytes and with a known size and duration. When you tell it to collect something from a CPW webcast it has a whole heap of problems:-

The file has no 'size' so you can't tell how the download is progressing.
There's no 'ID3' metadata showing when a track starts and finishes or explaining the track titles.
Flash Player can't see how much memory the listener's computer has - so it will try to store data until the computer crashes!
There's an outstanding bug in Flash Player 8/9 that gives an incorrect value for the amount of data downloaded when looking at Icecast2 or Shoutcast streams via a web browser (due to a missing 'content-length' header).
If the listener pauses playback the web browser (not Flash Player) can keep downloading the file in an attempt to help out and cache the content. It will carry on sucking until it falls over.

To make this work, Minicaster puts back the intelligence that Flash Player forgot. Instead of trying to collect the entire file, it collects a section of it (a few minutes or more), plays it back then throws it away. A new section is collected, and if possible the audio is crossfaded from one to another - then off we go again, forever if we want to. There's no problem with memory being filled provided the listening computer has enough free RAM to hold one section - and that's usually only a few megabytes. Now this isn't a complicated idea - it's the way plugins have been doing it for ages - but Flash has quite a bit of difficulty with this idea of 'throw away'. We need to be very careful how we handle the sound data, as even 'basic' Actionscript ideas like asking how much has downloaded can cause Flash Player to die. Minicaster is playing very close to the cutting edge of Flash Player 9's kernel, and with all due respect to our partners at Adobe, the cutting edge is a difficult place to be.

One of the latest 'bugs' to surface is the way audio streams are collected by the ActiveX plugin for Flash Player 9. For various reasons best left secret, we cannot always make two simultaneous connections to CPW data streams even if the server allows it. This bug affects both Internet Explorer and Firefox, when reading Shoutcast and Icecast2 data. As a result Minicaster has to detect the problem and work around it - if a second stream cannot be connected and the errors match those we know to come from this bug, Minicaster will revert to 'basic mode' and use a single stream. This introduces a one or two second drop in audio each time the data is dumped, but will ensure memory management works on all browsers.

Memory usage

Many people ask what Minicaster 'does' to memory usage, and the graphs below show the memory being allocated to Flash Player and IE7 on Windows XP running Minicaster, while it plays a simple 128kbps Icecast2 stream. In the first graph we have turned off the memory management system so you can see the way a 'normal' Flash audio player will consume more and more RAM - over 120MB per hour - killing a typical home PC within a few hours. In the other graphs, Minicaster's dumping system is active and you can see the RAM being maintained at a safe level. There is usually still a tiny upward trend caused by increases in the browser DOM heap and a really annoying memory leak in Flash Player 9, but the overall increase is very small indeed - a typical home PC would be happy playing this radio station for over a week!

Audio formats

Icecast2 allows sending music in non-MP3 formats (AAC, Ogg Vorbis, etc.). Flash Player can't understand anything except MP3 files - so before delivering a webcast through this playhead you need to check the radio station's format is pure MP3. You also need to ensure that the MP3 tracks are encoded at a 'standard' bitrate. For information on what bitrates Flash supports, refer to our guide. Minicaster has the intelligence to understand when and why a station can't be played, and it will stop trying and display an error.

We get asked a lot "when are you going to support other formats?" and the answer is "there are no plans to". It's not a case of writing Minicaster differently - Flash Player has an internal MP3 codec and there are no plans to allow the player to perform client-side audio decoding via operating-system registered codecs. Not only does that open a lot of problems with checking, updating and connecting to platform-dependent third party software, it also opens up some nasty security issues that we intend to keep closed.

Connecting to the top-level address on a Shoutcast server

Our playheads will deliver audio from both Icecast2 and Shoutcast, but there is a very important limit on audio from Shoutcast servers without a 'mount folder' - due to an oversight by the designers, Shoutcast uses the browser 'user agent' to decide if it sends MP3 data or a server status page. Since we're connecting to the server via a web browser, Shoutcast will always send the status page instead of the audio stream - silly but true. If your Shoutcast server uses a folder name in the stream, then it will connect perfectly.

For example if your Shoutcast server's stream is linked to:- http://my.shoutcast.xx:8000 then Minicaster will be unable to play the audio stream as it will be sent the status page instead. If your stream is linked to:- http://my.shoutcast.xx:8000/myradiostation then Minicaster will happily play the stream. The server port number (in this case 8000) has no impact on this process, it is the presence of a folder name (such as 'myradiostation') that makes all the difference. This is not an issue with Icecast2 as the status pages for Icecast2 are only supplied if specifically requested by the browser - the user agent is not important.

It is also impossible to collect the Now Playing data directly from Shoutcast, as there is no way for a Shoutcast server to send the 'crossdomain.xml' security policy file to Flash. It is possible to use a proxy script to pass the data through a normal webserver, and details are supplied within the PRO-ICE software package. Of course the webserver that runs your proxy script has to contain the crossdomain.xml policy file as well!