Streaming audio generally involves sending audio from one node on a network to another node. There are a number of ways in which this can be done, using a number of formats. This chapter briefly discusses some of them.
HTTP
HTTP is the protocol underlying the Web. The protocol is agnostic to the content it carries. While it was originally designed to carry HTML documents, it is now used to transport image files, Postscript documents, PowerPoint files, and almost anything else. This includes media files, the subject of this book.
HTTP Servers
Content is delivered from a web site by means of HTTP servers. The most well-known of these is Apache, but in the Linux world Nginx and Lighttpd are also common. There are a number of proprietary servers as well.
An HTTP server can deliver static files stored on the server or construct content dynamically from, for example, a database connection.
HTTP Clients
There are many clients for HTTP streams, generally known as user agents. These include browsers as well as many of the audio players discussed earlier.
HTTP Browsers
Point your browser to the URL of an audio file and it will pass the content to a helper that will attempt to play the file. The browser will choose the helper based on the file extension of the URL or based on the content type of the file as delivered in the HTTP header from the HTTP server.
MPlayer
MPlayer is HTTP-aware. You just give the URL of the file.
mplayer http://localhost/audio/enigma/audio_01.oggVLC
VLC is also HTTP-aware. You just give the URL of the file.
vlc http://localhost/audio/enigma/audio_01.oggStreaming vs. Downloading
If you download a file from the Web, then you can play it once it has finished downloading. This means that play is delayed until the entire file has been saved into the local file system. Since it is now local, it can play without worrying about network delays. Here is a simple shell script to illustrate this:
wget -O tmp http://localhost/audio/enigma/audio_01.oggmplayer tmprm tmp
The alternative is to read the resource from the Web and hand it as it is received to a player, using some sort of pipeline. This is fine as long as the pipeline is large enough to buffer enough of the resource so that it can cope with network delays. It is illustrated with the following:
wget -O - http://localhost/audio/enigma/audio_01.ogg | mplayer -(Yes, I know, MPlayer can stream URLs directly; I’m just making a point here.)
HTML5
HTML5 is the latest version of HTML. HTML5 is a “living standard.” Ugh! That means it isn’t a standard at all, but just a label for a specification that is in a state of flux. There is now an audio element, <audio>, that is implemented by many browsers.
For example, the following HTML will try the Ogg file first, and if the client cannot play it, it will try the MP3 file, and if it cannot play that, then it will display the failure message:
<audio controls="controls"<<source src="audio_01.ogg" type="audio/ogg"<<source src="audio_01.mp3" type="audio/mpeg"<Your browser does not support the audio element.</audio<
Figure 30-1 shows what it looks like in the browser.
Figure 30-1. Caption
DLNA
Digital Living Network Alliance (DLNA) is designed for sharing digital media such as photos, audio, and video in a home network. It is built on top of the Universal Plug and Play (UPnP) protocol suite. This in turn is built on one of the uglier of the Internet standards, SOAP. UPnP itself compounds this poor choice of base technologies by using what can only be described as an appallingly badly engineered hack in order to handle media information. With its most complex data type being a string, UPnP buries complete XML documents inside these strings so that one XML document contains another XML document as an embedded string. Oh dear, better-quality engineers could surely have come up with better solutions than this!
UPnP is open in that it can describe many different home network devices and formats of data. DLNA restricts this to only a few “approved” types and then makes the specification private, only available after paying a fee.
Despite all this, an increasing number of devices are “DLNA enabled” such as TVs, BluRay players, and so on. It seems like DLNA is here to stay.
Matthew Panton in “DLNA for media streamers—what does it all mean?” ( http://news.cnet.com/8301-17938_105-10007069-1.html ) pointed out some further issues with DLNA, mainly relating to the supported file formats. The truth of his comments are illustrated by my latest purchase of a Sony BDP-S390 BluRay player. It supports LPCM (.wav) as required, but out of the optional MP3, WMA9, AC-3, AAC, and ATRAC3plus, it only supports MP3, AAC/HE-AAC (.m4a), and WMA9 Standard (.wma). And of course, Ogg is nowhere in any of the DLNA lists.
The site DLNA Open Source Projects ( http://elinux.org/DLNA_Open_Source_Projects ) lists a number of Linux DLNA players. I have successfully used the CyberGarage Java client and server and the MediaTomb server.
Icecast
Shoutcast is a proprietary piece of server software for Internet streaming of audio, which has set the standard for streaming. Icecast is the serious open source competitor, which is just as good in quality and superior as open source and which supports a larger variety of formats. To the receiver of a stream, Icecast is just an HTTP server. The back end is the interesting part, as Icecast uses the Shoutcast protocol to receive audio from a variety of sources such as online radio, microphones, or playlists.
IceS is one of the ways that Icecast can get its audio streams and is included in the distro. For further information, see the IceS v2.0 documentation ( www.icecast.org/docs/ices-2.0.2/ ).
Flumotion
From the Flumotion site ( www.flumotion.net/ ), “Flumotion Streaming Software allows broadcasters and companies to stream content live and on demand in all the leading formats from a single server. Flumotion also offers a streaming platform and WebTV, which reduce workflow and costs by covering the entire streaming value chain. This end-to-end yet modular solution includes signal acquisition, encoding, multi-format transcoding, streaming of contents, and state-of-the art interface design. The media back office allows for advanced content management and optimal monetization through rich media advertising.”
Conclusion
This chapter gave a brief overview of some of the streaming mechanisms available. HTML5 embedding provides an easy way of including audio (and video) into web pages, while systems such as Icecast and Flumotion can be used for professional audio systems such as radio stations.