Streaming Architecture


Except for the occasional voiceover or live in-studio programming, all SomaFM music is streamed from pre-encoded on-demand MP3 audio files.

Figure 9.1. SomaFM: Diagram of audio pathway from DJ to Internet listener.

graphics/09fig01.gif

Formats Used

SomaFM broadcasts its programs in the MP3 format, typically providing three bit rates for each program (128Kbps 44.1kHz stereo, 56Kbps 44.1kHz mono, and 24Kbps 22kHz mono). MP3 was chosen as the only format because it's an open standard and server software costs are nil.

Encoders

SomaFM first encoded on-demand MP3 files at 160Kbps, later bumping up to 192Kbps to avoid undesired audio artifacts resulting from re-encoding the on-demand files to lower bit rates as part of the live stream. But while encoding on-demand MP3 files at 192Kbps is suitable for a typical audience listening quietly on computer speakers at the office, it was decided to increase the bit rate to 256Kbps, before settling on a 320Kbps minimum, mostly because disk space is so inexpensive. The higher bit rate encode settings are useful as SomaFM is considering offering its content for satellite radio services.

The majority of these pre-encoded MP3 source files are ripped and encoded from CDs on a Macintosh computer with SoundJam (www.soundjam.com) using the Fraunhofer encoding engine. The SoundJam team was tapped by Apple to help create iTunes and SoundJam is considered the precursor to Apple's music file jukebox software. SoundJam is no longer available, but Hodge remains comfortable with the program's playlist creation features and uses them to maintain master playlist information for each program.

The on-demand MP3 files and program playlists are copied to and stored on a Linux server computer that then shares those files with each of the individual stream's authoring computers. These LAN file transfers are done using the freely available software packages netatalk (the AppleTalk Protocol Suite for Unix) and Samba (Windows file sharing software for Unix).

Each of the program's playlists are updated by hand as new songs are added and old ones removed, or a song's number of plays per program run is changed. To help make things easier, Hodge has a custom-built AppleScript program to automatically copy his playlist onto the Linux server. Each of the programs has a separate playlist folder that includes current songs as well as a list of tracks that have been temporarily removed. To repeat songs within a program Hodge's current approach is to simply list the song multiple times in the appropriate playlist. He acknowledges the solution is inelegant but mentions it's temporary.

Each program has its own dedicated authoring computer that encodes a live stream for each bit rate offered. These authoring computers cost about $350 apiece and are assembled from older hardware found by scouring for good deals at Web sites such as www.pricewatch.com. A typical configuration combines an Intel motherboard with a Celeron processor (400 900MHz), a 20GB hard drive, 128MB RAM, and a Creative Labs Sound Blaster Live "value package" audio card. Prices for memory and disk space have dropped recently, so adding more of both is appealing. Hodge prefers Intel and 3Com networking cards. He feels that other brands have presented problems with SHOUTcast streams, and suggests that the incompatibilities may be a result of the way the network packets are formed.

Each of the individual programs' Windows authoring computers maintains a local copy (pulled from MP3 files on the Linux server) of all the music needed for its specific program. This technique increases the computers' stability and also makes it possible to take the server down for maintenance without interrupting the programs.

To author multiple bit rate streams for each specific program, all authoring computers run a copy of the OtsJuke DJ (www.otsjuke.com) software package for "DJs, radio stations, & music lovers." Free evaluation copies are available from their Web site. This software acts like traditional radio station automation; supporting playlist creation, cross fades, live source mixing, and other features.

SomaFM uses the OtsJuke software's playlist generation feature as a starting point for each stream. Hodge sets up the OtsJuke playlist with a randomly ordered list from his master database and applies a few rules such as "Don't play same artists within 15 tracks" and "Don't play same track name within 100 songs." Some of these rules are of a legal nature (Digital Millennium Copyright Act see Appendix for more details), and some are simply programming common sense. Because permissions to play about 50% (this number has been steadily rising) of SomaFM's programming comes directly from artists/labels (copyright holders), SomaFM can legally work around many of the DMCA rules. Playlists are fine-tuned while the program streams.

For SomaFM in general and Hodge in particular, the coolest thing about OtsJuke is its direct support for SHOUTcast authoring. OtsJuke has a built-in dynamics processor with automatic gain control (AGC) and a compressor/limiter. The OtsJuke AGC is tunable and, for SomaFM, is currently configured to a fairly long time set. The AGC dynamics processor is only single-band, but it does the job adequately. SomaFM uses dynamic processing slightly differently on each streaming program. For example, the Groove Salad program uses AGC more aggressively than the Drone Zone program. Many listeners are at work, listening on inexpensive computer speakers at low volumes. If they turn their volume up to hear a quiet section, the louder sections of an otherwise unprocessed stream are too loud, and vice versa. AGC dynamics processing is almost mandatory when creating programming with many different kinds of music from many different sources. Streaming programming of this type that doesn't use dynamic processing clearly shows radically unequal volume levels between songs.

SomaFM routes live audio (CD, mic, in-studio performance) through a standalone Behringer 9024 ($400) six-band compressor/limiter prior to including it into a streaming program.

Servers and Bandwidth

All of SomaFM's authoring computers as well as the Web and e-mail server are connected through two 1.5MB sDSL lines. At the time of this writing, one line handles four of a current total of six programs, and the other line hosts the last two programs as well as the Web and e-mail server. All the authoring computers' streams are broadcast to a local SHOUTcast server. Reflector SHOUTcast servers that serve the Internet listeners then pick up one copy of each of the three bit rate streams for every program.

Discounting the Web and e-mail traffic, basic addition seems to show that enough bandwidth exists to stream the current six programs over a single 1.5Mb sDSL connection. Each program streams a 128Kbps, 56Kbps, and 24Kbps feed, totaling 208Kbps per program. Multiply that by six (the number of programs), and the total is 1,248Kbps. That leaves 252Kb of connectivity for administration, e-mail and Web traffic. Unfortunately, it's not that straightforward. Each stream requires a certain amount of headroom for reliability and stability. In fact, Hodge's experience has shown a headroom level of 20% (minimum) over and above each individual stream's bit rate is required. Splitting SomaFM's programming across two connections is necessary to ensure broadcast stability.

SomaFM doesn't have enough cash to afford the bandwidth required for streaming redistribution to listeners from within its own network. Consequently, the streams travel over the Internet to various banks of streaming SHOUTcast server computers. Companies that have spare bandwidth donate servers and bandwidth. These companies have contracted with their ISPs for extra bandwidth to handle their peak usage, and at non-peak times these companies have more bandwidth than they need. Donations of this nature are a strong testament to the positive impact of SomaFM's programming and negotiation abilities. The audience continues to grow, and SomaFM is always on the lookout for more bandwidth. Hodge recently found some in the SHOUTcast developers. SHOUTcast's corporate owner, AOL/Time Warner, had an enormous number of servers and huge amounts of available bandwidth and needed to promote their own streaming services. Through a special offer, certain handpicked stations (of which SomaFM was one lucky recipient) were given access to additional servers and bandwidth. To qualify for the free assistance stations had to fall within certain guidelines, including showing 50 100 peak concurrent listeners consistently. Stations also had to have exceeded their current resources, have no commercials, and show a measure of longevity. As a final decree, SHOUTcast stated it would not offer this promotional service to any streaming station whose programming could be described as "techno."

Although it's possible to serve SomaFM's peak use of more than 2,000 concurrent listeners on fewer (but more powerful) servers, SomaFM's current bandwidth and server arrangements occupy five server computers. In theory, it should be possible to fit eight listeners using 128Kbps streams on 1Mb of bandwidth before saturating a 100Mb (100B-T) connection. SomaFM current guidelines are 600 users per server, although they have peaked to 700 listeners. Most of the SomaFM SHOUTcast servers are running on other people's computers and bandwidth, but Hodge and his crew handle all of the administration duties.



Streaming Audio. The FezGuys' Guide
Streaming Audio: The FezGuys Guide
ISBN: B000H2N1T8
EAN: N/A
Year: 2001
Pages: 119

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net