Streaming on a Shoestring

By Doug Kaye

From Web Hosting Monthly, February 2004 Edition

February 16, 2003 -- (WEB HOST INDUSTRY REVIEW) -- About a year ago I decided to build IT Conversations, a Web site of recorded audio interviews, and I wanted to do it for essentially no money. I was already running a Linux/Apache server, but nothing else. The project is still evolving, and what follows is by no means an exhaustive exploration of the options, but my experiences to date should be enough of a guide for anyone who's got the same ambitions and budget to get started.

We're all familiar with the Windows Media Player (WMP) and the RealPlayer (RP), since most high-end streaming sites tend to deliver content encoded for one or both. The players are free, but RealNetworks charges for its Helix servers, and the latest Windows Media Services run only on Windows Server 2003. Either option would have cost something. Besides, I had in mind that listeners would like the option to download .mp3 files into their iPods and other players, and I wondered if there was a way to stream those same .mp3 files rather than use proprietary .rm or .wma files.

I found two free server solutions. SHOUTcast (shoutcast.org) from Nullsoft, suppliers of the Winamp audio client for Windows, is available for Windows, OS X, FreeBSD, Linux, and Solaris, and can deliver streaming and on-demand .mp3 files. Icecast (icecast.org), an open-source project available in source or pre-packaged for Windows or Red Hat Linux, supports .mp3 and Ogg Vorbis (.ogg) files. The latter format can be important, since there are intellectual-property rights associated with the creation and distribution of .mp3 files. I found both servers very easy to install, although I had to do a little digging to uncover all the configuration documentation I needed for on-demand streaming. (Two options I didn't test are the mod_mp3 Apache add-on and GNUMP3d.)

The most significant difference between both of the .mp3 and .ogg solutions and the proprietary RealNetworks and Microsoft technologies is the protocols they use. By default, Real's Helix server uses PNM and RTSP listening on ports 7070 and 554, respectively, while Microsoft's server typically uses its own protocol over UDP or TCP on port 1755. SHOUTcast and Icecast, however, both use good old HTTP, nominally over port 8000. From an .mp3-streaming client's perspective, SHOUTcast and Icecast appear identical.

Until recently, users who wanted to listen to streamed .mp3 files had to download one of the specialty players such as Sonique, Macast, SoundJam, Winamp 2.x, 5.x (not 3.x) or Zinf. But just recently, the mainstream players have added support for .mp3 streaming, so visitors can now use the latest versions of iTunes, Windows Media Player, and RealPlayer.

So that takes care of the servers and players, but what about the source material? Streaming servers depend on small metafiles. RealNetworks uses .ram and .rpm files to specify content for standalone players and browser-embedded content respectively. The formats are simple - they merely contain the URLs of the actual content - but they must be delivered with the proper MIME types. Similarly, Microsoft uses ASX metafiles containing XML and allow for the optional specification of various metadata such as artist, title, copyright information, etc.

In the non-proprietary world of streaming .mp3 files, there are two metafile playlist files: .m3u and .pls. The former originated with Winamp, but the latter now seems to be the more widely used. Both are simple text files containing the URLs of the .mp3 files and, in the case of .m3u, a bit more information. You can create playlists with a text editor, or you can write scripts to create them in batch or on-the-fly.

The most important conclusion I've drawn from my experiments is that it's now quite practical to offer streaming audio without an expensive proprietary server. So long as you stick to HTTP, you can stream virtually every type of compressed audio file: .mp3, .ogg, .rm and .wm, and you can do it with free software, even a standard web server. The results may not scale as well as when using a specialized protocol, and a few users may experience more connection and buffering problems, but my experience has been that these problems are minimal for low-volume sites.