STLs and Raspberry Pi(e)s

So, you’ve got this neat little radio station in town and a transmitter on top of a windy hill. Sounds awesome but have you ever considered how you get your Sony Award winning* programming out there? Well, the answer is a Studio Transmitter Link (STL).

Now, on your big commerical radio stations, this link tends to be a dedicated digital circuit like Kilostream. Sounds great but any engineer with more than 10 seconds experience on the job will tell you things break. Oh, and things like squirrels and rain may knock things out temporarily. So, you use something like ISDN as backup (and you thought it went the way of the dodo when ADSL became popular). Or, if you’re a bit stuffed at that point, you can always rebroadcast another transmitter (risky if you’re enjoying atmospherics or have some nutjob hell bent on delivering their view on the world).

Even then you’ve got a CD with “bangin’ choons” from about 10 years ago ready to play at the transmitter site if things go wrong. But what if you can’t afford this sort of stuff. Well, you have to get creative. Many community stations are turning to point-to-point WiFi links. Low cost and occasionally suffer from rain fade but not bad for the cost.

There’s also FM links, ADSL lines and even older circuits like Musicline One or balanced twisted pair. And that’s what one station I’m helping has been using for a very long time now. In fact, the line dates back so far that it used to be patched in at the exchange for OBs!

However, it is one of the few of these lines that still existed between two exchanges. And this proved a bit of a problem when the line suddenly went down with no warning. Turns out there was some work at one of the exchanges to remove old bits of kit. Guess who’s line was among that kit. Now, we did get a hasty EPS replacement thrown in between the two exchanges but for the price this station’s being charged and because it’s likely to happen again, we’re looking at new options.

And that’s where the Raspberry Pi comes in. This station is closed loop so has no real transmitter to worry about and does not derive revenue from on-air content. Upshot is we can be fallible (to an extent).

This all means we’re now ordering an ADSL line for the remote end and sticking a Raspberry Pi in to pick up a web stream. Admittedly the Barix Extreamer is very nice but a bit costly for our purposes. On top of that, we can configure the Pi to have some more complex fallback and alerting options with the LiquidSoap software. And that’s what I’m going to talk you through – setting up a Pi as a remote end codec.

So, without further ado:

  1. Acquire a Raspberry Pi. Purchasing one from CPC/Farnell is much more appreciated than nicking one from your colleague.
  2. Install Raspbian. It’s not that complicated and there’s a lot of guides out there. However, when you get to the installer wizard bit, we want as little RAM as possible for the GPU (I don’t know of many codecs that need 3D graphics with fancy shaders), to turn off boot to desktop, to set a sensible password for the pi account and to enable SSH.
  3. Fire up your Pi and install LiquidSoap. The command is literally
    apt-get install liquidsoap
  4. If you’re pulling an MP3 stream or planning on using MP3 backup audio, you’ll need to install some of the LiquidSoap plugins.
  5. Create a file called /home/pi/stl.liq and bung in the following contents:
    # STL Liquidsoap Config
    # Logging
    
    set("log.file.path", "/home/pi/log/liquidsoap.log")
    
    # Setup our sources
    
    main_url = "http://yourserver:8000/stream_name"
    emergency_audio = "/home/pi/emg.wav"
    
    # Now our e-mail alert routine
    
    def silenceHandler()
     system("/home/pi/mailsend.pl");
    end
    
    # Our main source is streaming with silence detection
    
    radio_stream = input.http(main_url)
    radio_stream = on_blank(silenceHandler, radio_stream)
    
    # Fall back to an MP3 file
    # Also worth noting, if we get this far, we ought to tell someone (if we can)
    
    emg_file = single(emergency_audio)
    radio_stream = fallback(track_sensitive = false, [radio_stream, emg_file])
    
    # Finally, pump it out the soundcard
    
    output.alsa(radio_stream)
    
  6. Add a line to /etc/rc.local before the exit command with the following:
    sudo -u pi liquidsoap /home/pi/stl.liq &


    That will start LiquidSoap on boot –  awsome.

  7. Copy a backup audio file to the Pi. On this system we called it emg.wav. You can call it whatever you want but you will need to change the above script.
  8. Run alsamixer and bump the levels all the way up (for most installs).
  9. Reboot and you’ll have a little codec. Try pulling the network lead out and seeing what happens.

So, that’s is all configured and running but what does it do. Well, by default it will pull a web stream from the URL of your choice and play it out of the sound card. If it goes silent, it runs a script called mailsend.pl. This is a shifty little script that we have to e-mail us when things go silent.

However, if the stream fails completely, we fall back to playing the emg.wav file on loop. Sounds good but it’s worth remembering that it will resume the backup file from wherever it stopped last on every subsequent failure. While that might sound odd to the ear, you don’t end up hearing “She Wolf” every three minutes when the ADSL line flaps.

*May not actually be Sony Award winning.

Tags: , ,

3 responses to “STLs and Raspberry Pi(e)s”

  1. quad says :

    Hi,
    I’m trying your solution but if i run
    liquidsoap /home/pi/stl.liq &
    It say me “linea 3, char 2: empty token” what i am doing wrong?

  2. mike909 says :

    Hi nice script… only i get: variable output.alsa used here has not been previously defined.

  3. mike909 says :

    Hello,

    I hope some one can help me to run your script.

    We get:
    sudo -u pi liquidsoap /home/pi/stl.liq

    At line 30, char 12: the variable output.alsa used here has not been
    previously defined.

    Best regards,
    Michel

Leave a comment