Server Stream Distribution

Server stream distribution is the process of delivering your audio content to your listeners. Without a server to take your audio programming and send it to listeners for you, you would need to make a connection from the authoring computer to each listener. Server stream distribution is also much easier and more efficient than e-mailing the content as an attachment to each person who wants to listen to it.

Unicast Versus Multicast

Streaming servers deliver audio to listeners in two primary ways. The first method, unicast, involves each listener receiving his own copy of the audio stream, like two cups connected by a string. A streaming server in unicast with 100 listeners would have a complex web of 100 cups and strings. In unicast, each listener requires as much bandwidth as the stream to which they are listening. This means that 100 users listening to your 24Kbps audio stream requires 2.4Mbps of bandwidth. (For more details about bandwidth, see Chapter 2.)

The other delivery method, multicast, involves multiple users on a network sharing the same bandwidth. This is the same as a traditional terrestrial radio station sending out signals into the airwaves just once and everyone within range tuning in to whatever is playing at that moment. On-demand content is typically not delivered via multicast because it's rare that multiple users will click on the same on-demand link at the same time. However, multicast holds the future of live streaming because it's a more efficient delivery method and can save enormously on bandwidth costs. Multicast also spreads bandwidth costs across many networks instead of focusing them all at one location. This makes it possible to avoid interruptions by obtaining programming from a different network path if problems exist. Of course, some people don't like the idea of having to pay for someone else's bandwidth, and this is one of the many issues to be resolved before multicast becomes the standard.

Unicast is still the standard streaming delivery model. For this reason, it will be used for the examples in this book.

Progressive (or HTTP) Versus Real-time Streaming

Real-time streaming occurs when a two-way conversation exists between the streaming audio player on the listener's computer and the streaming server. Advanced technologies take advantage of this two-way conversation to provide features such as "seeking" to a different location, switching to a lower-bandwidth stream (in case of interruptions), or deciding that a larger buffer is required. Some users behind firewalls can have problems streaming content from a realtime streaming server.

Progressive streaming (also called progressive download or HTTP streaming) occurs when a player application plays the audio as it receives a stream without being able to change the stream after it has begun.

Comparing the two technologies, imagine that you ordered food in a restaurant and then decided to have your dessert served before your main course. Real-time streaming could handle your request, but progressive streaming will make you wait until everything else has been served.

Progressive streaming is worth using because it can be done through any Web server (hence its other HTTP name). Audio streams delivered through a Web server avoid most firewall problems because typical firewall configurations allow web traffic.

Because real-time is the most common and feature-full type of streaming, this book uses it for most of its examples.