Tuesday 16 February 2010

Handling Power Loss - Cost vs Benefit

As part of my day-to-day life, I'm currently holding the president position in WiredSoc (the student computer science society in St. Andrews). It's an interesting and challenging position to hold.

One of the responsibilities I have (and delegate to some extent) is the reliable operation of WiredSoc's servers. Specifically it's me or the systems administrator that get complained to if something goes wrong.

This brings me onto a recent outage we had. At approximately 1am on Monday morning, services disappeared due to a brief power interruption/surge (I've got conflicting reports on that one). 2 of out 3 severs dropped out and came back online. Our public facing server came back online at about 9am and only after I manually kicked it into action.

Now an 8 hour outage on a voluntary service - is it acceptable? I would say yes. There is no way I'm going to force someone to go onsite at 2am to fix a problem when there is no compensation available. It's just beyond the bounds of acceptability! Really, would you volunteer to do it?

Also, a UPS (uninterrupted power supply, basically a battery used to keep computers ticking over in power loss) is out of the question - too costly and of little benefit. Realistically, power outages tend to take out our connectivity as well. So, we could remain powered up but of no use to anyone!

This leads me onto a similar problem I also saw with STAR's systems when I was in charge of those. Would it have been worth installing a UPS if we had the budget? Nope - power outages again took out the network and server. So, even if the studio was still live, we could not get the broadcast out (we were an online station).

In conclusion, it is my opinion that voluntary projects should strive for high availability. However, it should also be taken into consideration that it is not the end of the world if your service disappears temporarily.

Monday 15 February 2010

A Lick Of Paint

There's many benefits to developing AllDay DJ in Java. These include the usual things like cross-platform support on a whim (I'm developing and testing on both Windows and Linux).

Also, the Swing toolkit (the library I use to build the user interface) comes with support for "Look and Feel". This leads me to one of the more frivolous benefits - the ability to change how AllDay DJ looks on a whim.

After a bit of mucking about on the internet I found the NIMROD look and feel. After a bit of tweaking, this is what AllDay DJ 3 now looks like:




I'm sure you'll agree, it's much easier on the eye.

Wednesday 10 February 2010

Radio Station In A (Linux) Box

It's an interesting concept - is it possible to go from source audio file (mp3, wav, ogg) to a complete streaming station on just one computer system. The answer is yes and with only one soundcard too! (Though the software I developed and use can punt out to many soundcards for live use).

This past week or so, I've put together an internal test stream for AllDay DJ 3. This is mainly to prove it's up to the challenge. Also, it means I can run this on a headless (no monitor) system in a rack that I don't need for things like coursework. I can also get the music on any computer in the house then - very useful!

So, let's talk through the components, starting with the system itself. Well, it's your off the shelf Linux box. The one I'm using currently runs Gentoo (not my choice) but I have also done this with a stable Debian system.

Basic system in place, let's get our audio playing. A silent radio station is useless!

I installed PostgreSQL, a VNC server and Sun Java 6. This is enough to get AllDay DJ 3 ticking over. My music library (now categorised and rather broad spectrum) and some jingles I knocked together were loaded. At this point, I have a playout system pushing audio out to the sound card and sounding a bit like a radio station. The music choice got a bit of a mixed response from friends helping with the project. :P

Now, we've got our audio - how do we get it to the audience of one (me!). Well, that requires streaming. There's two components to this - the streaming source and the streaming server.

If you're not up with the terminology: the streaming source (as I've called it), is the piece of software that captures the audio then sends it to the streaming server. The streaming server then supplies copies of this stream to the listener.

Being a Linux box, I went open source. Initially I used Darkice as the source software and Icecast as the server software. Simply tell darkice to use the "Stereo Mix" as a source. It worked and I got an MP3 stream direct to my desktop.

However, it sounded a bit lifeless, especially compared to what you hear on the dial. Time to add some audio processing.

Now, I don't own a compressor and whatnot that I could plug into the audio stream. Also, it kills the idea of using the "Stereo Mix" source if I have to use external kit. To top it off, most audio processing kit can't be adjusted remotely.

What I needed was a software solution. Thankfully one exists. It means I have to move from an MP3 stream to an OGG stream. That's not a huge issue.

The solution is to make use of ecasound and ices. Both are tools that I had not heard of before until recently but due to the stdin/stdout support, they can be tied together without the need for another sound card - useful!

Now the command line I used to launch the internal stream is:
ecasound -i alsahw,0,0 -o stdout -eca:10,0.01,1,1 -ea:500 | ices /etc/ices2/ices.xml

This tells ecasound to take take audio from the first alsa sound card (set to record from "Stereo Mix" using alsamixer). The "-o stdout" bit tells ecasound to spew out to the ices streaming source software.

The next parts of the ecasound command are the inteseting parts.
"-eca:10,0.01,1,1" is the compressor settings. It means knee at 10%, attack of 0.01s then use a 1:1 ratio (I just want everything level / heavily compressed to start with, I'll adjust later). "-ea:500" just means amplify 500% (or 5x).

The final part of the command tells "ices" to launch with the correct config file. This has details of my server and to take an audio stream from stdin.

The suprising result of all this is that it possible to run an radio station from a Linux box. All be it one that streams on a closed network.