How can I optimize an audio streaming setup?

December 12, 2006 4:35 PM

How can I optimize the audio streaming setup that is the core of the low power radio station I work with?

The low power radio station I work with utilizes shoutcast streaming to distribute audio from our studio to our two transmitter locations, and to a public streaming server for internet listeners. The setup is basically like this:

1. studio shoutcast server
    \_2. main transmitter player/server (mirror)
        \_ 3. public streaming server (mirror)
            \_ 4. secondary transmitter player
            \_ 5. internet listeners

So 1 is a shoutcast box serving up whatever the DJ in the studio is playing. 2 listens to that stream, and mirrors it out on its own shoutcast server. It also plays MP3 playlists from itself when no one is in the studio. 3 is a public hosted server that we pay for monthly, which mirrors the feeds for regular internet users, and the secondary transmitter is really just treated like one of those. 1 and 2 have DSL connections, with 512k upstream, but the usual consumer internet reliability issues.

As you can see, if that diagram is at all comprehensible, the main transmitter site is a single point of failure. If that can't connect to the studio for any reason, everything else falls offline. Because it's just a cobbled-together Windows box running on home DSL, it craps out often enough to be annoying.

My proposed fix is to replace the server component of 2 with a colocated Linux box that will provide the same functionality. It will connect to the studio and pull the stream served from there, and mirror it out equally to both transmitters and the public streaming server. So the new diagram would be like this:

1. studio shoutcast server
    \_ 2. colocated player/server (mirror)
        \_ 3. primary transmitter
        \_ 4. secondary transmitter
        \_ 5. public streaming server (mirror)
            \_ 6. internet listeners

Now 2 is the single point of failure, but it has been made far more reliable. If its connection to 1 goes down, it can flip over to playing MP3s for 3, 4, and 5. If any of 3-5 go down, only one group of listeners is cut off, instead of all of them. I think this solution makes the most sense, but I don't have a lot of experience with this stuff. I'd be glad to hear any other architecture type advice, or pitfalls I might want to look out for. Thanks!

posted by autojack to Computers & Internet (2 answers total)

It sounds like you know more about the issue than any of us, which is why you've received no responses.

Can you throw station-identification and technical-difficulties mp3s into the failover playlist at regular intervals, so people understand why their favorite deejay hasn't talked in a while? ;)

One potential problem with any system that relies on the internet as its transport was exemplified in the level3-versus-cogent pissing match some time back: if your endpoints are on different parts of the net, reachability isn't guaranteed.

Depending on your budget and stream bandwidth, you might look at ISDN as a point to point, reasonably quick data connection between the studio and the colocated server. On its face it seems like you're trading the evils of DSL for the evils of ISDN, but consider this: Many DSL circuits go through multiple layers of encapsulated backhaul to a distant city before they're routed, and a failure at any point in that chain would cut off two DSL-connected endpoints, even if they're next door to each other. ISDN on the other hand is handled locally, at the LEC's switch, and has fewer links in its chain that could potentially break. (It would also exhibit lower end-to-end latency because of this, though I doubt that's important in your application.)

Then again, that might be a terrible idea, if your local telco is clueless, expensive, or both. Most are both.
posted by Myself at 9:05 PM on December 13, 2006

Response by poster: Yeah, I figured it was hit or miss whether anyone would be able to add anything to my planned improvements : ) I'm not sure what the level3-vs-cogent thing is you're referring to, but I take your point; the internet is inherently unreliable. When I was studying for CCNA, I was surprised at how heavy it was on the concept of private data circuits connecting regional offices and whatnot. I asked if anyone really did that anymore, and one of my classmates explained that he worked for a bank where the concept of routing data over the internet, even with VPN for security, was laughable from a reliability standpoint.

ISDN would be a nice solution, and I know that one of the places where it is still commonly used is in FM broadcast applications for live remotes and whatnot. However, even if it were within our budget, it doesn't really work for more practical reasons: due to our dubious legal status, we're forced to move the transmitters occasionally. We rely on the gratitude of friends to host us, and since everyone has a broadband internet connection, it's easy enough to plug into that. Setting up DSL every time we move would be much too complex, even absent your very correct point about local telcos. Additionally, only the studio and primary transmitter are geographically close. The secondary and now, I'm told, tertiary, transmitters are in other cities.

I suspect my plans to combine a colocated server with a move to Linux will make a huge difference. Link reliability will be much higher, and I'll be able to write a lot of monitoring and management scripts to keep an eye on things. I'll never love Windows as a server.
posted by autojack at 12:13 PM on December 14, 2006