Uncompatible Systems

I’m exploring the option of using a single, authoritative URL for a broadcast which can be sourced from a constantly changing number of locations without the listener being aware of this fact. Icecast 2.3.1 has all the configuration and administration options for this to be possible on paper, though in practicality, this is proving close to impossible using only the options in Icecast.

Icecast 2 has a concept called fallback mounts. This means that a mountpoint can be configured to have a secondary mountpoint to fall back to in the case that the first’s source disconnected. This peaked my interest since it also includes the option to fallback to the primary when it’s source reconnects. An obvious use for this is an “all circuits are busy” kind of message in the case the the primary is offline and the ability to remove the message automatically when the primary comes back.

But what if this could be used to switch between a primary source and many different sources which are broadcast from remote live locations, without requiring the listener to reconnect? It turns out that not only does Icecast offer a way to define a static mount point as a fallback, it also has an interface via HTTP to update the fallback for any mountpoint. This means that a dynamic fallback can be configured for a single static mount.

In practice, the current release of Icecast makes this difficult, if not impossible. The dynamic fallback configuration functions erratically, if at all. A dynamic fallback cannot be configured to reconnect to the primary source when it reconnects. This could be solved by detecting when the source reconnects and issuing a move listeners HTTP command to the server to bring them back. But this also isn’t good enough because if the primary source is offline, and a listener connects to it, HE WILL NOT FALLBACK TO THE DYNAMIC MOUNTPOINT! Said listener will get nothing, a 404 error that the source isn’t connected. If there is a static fallback defined in the Icecast configuration, the listener will be connected to this one. This is obviously a bug, though the Icecast release hasn’t been updated since 2005 so I’m not expecting anything to be done for me.

After ruling out dynamic fallbacks via HTTP, I moved to another option. If fallbacks can only be configured properly in the server XML file, then I’d have to make an interface to modify that file when a live source connects and reload the server configuration to update the fallback. This would produce the same results as HTTP fallbacks but would function properly.

So I tried it and it worked…but.

There appears to be a problem with changing a stream’s source with the mp3 codec and iTunes as the listener. Each time a fallback sequence is executed, listen to primary, kill primary, listen to fallback, restart primary, listen to primary, the audio begins to skip, much like a dirty CD. After about 30 seconds, the stream will either “fix itself” by rapidly skipping until it stopps, like it’s trying to catch up to something or the server will disconnect with the error that iTunes couldn’t keep up. I don’t know if it’s the client or the server that’s causing this. I’ll do tests with other clients and codecs.

So for now there’s only one solution I can think of despite all these limitations. Generate a unique URL which points to a script with a query string. The script will parse this query string and reply with a HTTP 302 Moved Temporarily redirect to the proper Icecast stream. The mountpoint that is defined as the “proper stream” is held in a database and can be changed through a standard client interface. The end result? A single authoritative server URL, despite the fact that the stream URLs are constantly changing. But what about the people already listening when a stream URL gets updated? They will have to be moved via an HTTP request to the server.

Turns out that on the protocol level, Live365’s “Nanocaster” broadcast server functions exactly the same as Shoutcast. I downloaded the demo of Nicecast, which is the well-featured “internet radio” package for OS X. Personally, I dislike Nicecast a lot. I won’t get into those reasons here. What made it necessary for this experiment is that it has two separate broadcast modes. One labeled “Shoutcast” and one labeled “Live365″. I configured the exact same settings for each server mode. Then I set up a network analyizer called Wireshark (formerly know as Ethereal) on the IP of the Live365 server.

Results? Both “Live365″ and “Shoutcast” modes worked with a single Live365 account. The underlying protocol as displayed by Wireshark is identical for both modes. So what’s this mean? This means that I can use any Shoutcasat compatible application to send a source to Live365.

Unfortunately, Darkice is still giving me errors. Gotta see what Wireshark says on that end.

Archiving with Visecas was functional but somehow consumed 100% of my CPU, whereas calling the same chain through ecasound directly consumed 20%. I’d like to contact the author but I won’t for now since I’m working on other things. In the mean time, archiving is handled through a separate laptop with a line-in running Audacity. Clumsy overkill but hey, it works.

After targeting the network congestion issue with Darkice, I moved on to the next step in the chain. A step I haven’t wrote about here yet. Interoperation with Live365. Live365 is a proprietary streaming platform for Internet radio. My goal is to phase out Live365 by slowly integrating it with Icecast.

The first step is to eliminate the Studio365-Live client software. This software functions exactly the same as Darkice, though it’s proprietary and doesn’t go through much development. Eliminating this can be accomplished by switching Live365 to “Relay mode”. The configuration for this is a single IP address and port number. This format is not immediately compatible with Icecast, since Icecast has the concept of “mount points”. Fortunately, Icecast can define a “default mount point” of “/” which will let Live365 enter relay mode.

The second limitation is that Live365 only uses the mp3 codec, so the default Icecast stream must be mp3. The third limitation is that Darkice has trouble encoding seemingly random bitrate/channel/samplerate configurations of mp3. My first try was at 56k/22050/mono. This required darkice to sum the stereo signal and resample to half of what’s coming in the other end. Both of these functions can be handled by the LAME encoder, though apparently not that well in realtime. Perhaps enhancing darkice to use libsndfile might help?

The fourth limitation is Live365’s proprietary “Nanocaster” streaming server. This streaming server seems to get the source from my Icecast server every so often. This should only happen if it loses it’s own connection. When it reconnects, there is a short skip in the playback. There have been times when this happens every minute, and the user experience is one of a CD skipping. I can confirm that this is coming from Live365’s end since I can listen to the same stream Nanocaster is listening to directly from the Icecast server. This random skipping doesn’t happen despite my Icecast server’s logs producing messages from Nanocaster.