Posts Tagged ‘radio’


Radio station across town


Recently, I’ve been heavily involved with the transition involved with moving the radio station out of its downtown office and into the new office known as Burnt Mill. Here are a few things I’ve done lately:

– Wrote a console peak meter.
It’s desirable to avoid running an X11 server, and imperative to never put any critical server processes on top of it. The GUI is a nice tool that has its place, but for a system to boot quickly, it must only perform the necessary tasks to revive critical services (in this case, audio streaming). On a similar note, my systems should probably migrate from ext2 to ext3, since journaling will mitigate time lost to running filesystem check (fsck) every twenty-third boot.

I first did a prototype using #!/bin/bash but was unsatisfied by the load placed on the processor. As it turns out, if you use C you don’t have to open and close the device four times every second. You can open it once at runtime and then just use ioclts to get info from the device. My approach was then to take the existing code base of OSS 4.x (Open Sound System — the acronym is ambiguous since it also refers to Open Source Software), modify ossmix.c in place and recompile. By trimming all methods related to write operations, and all unnecessary constants related to objects other than VUMETER, I was able to easily port the shell scrpit’s echo commands which were written using ANSI for colors and some box-drawing Unicode glyphs. I have yet to develop a method to detect whether the shell supports Unicode, but I have gotten some funky results using Putty’s default translation settings (ISO-8859-1). ASCII art using apostrophes, full stops, and hyphens should be sufficient for most.

– Increased latency on the Delta 1010 connected to the on-air system
We’re using a combination of FMPEG and VideoLAN Client to transmit audio from point to point and have had a lot of “audio output is starving” messages. At first, it was packets being dropped. After notifying our provider, they did some investigating, and I haven’t seen any UDP checksum errors since. However, the drivers must communicate effectively with the applications, and must be scheduled accordingly. By changing the /usr/lib/oss/conf/oss_envy24.conf to have envy24_nfrags to a lower number, I reduced the number of messages logged about starving by an order of magnitude.

– Found out that Shoutcast is now being heavily claimed by AOL
Apparently they want royalties for licensing the official Fraunhofer MP3 encoder in order to use their software, and they don’t want VideoLAN to have Shoutcast capability due to licensing conflicts. I could go ahead and use the old version of the software that has been running for over five years on an older machine, or I could move to Icecast which is open sourced.

OSS has its advantages, such as troubleshooting USB drivers. We have a Behringer UCA-202 that we’re trying to use as an audio input to the streaming server. Of course I’d be much happier if it just worked, but OSS has just recently gone open source [again], so I’m prepared to contribute when necessary. By taking the suggestion to modify the src/kernel/drv/oss_usb/ossudb_audio.c file’s write_control_value function to return 1; things started to work (somewhat). Unfortunately the sound card is locked to 48000 sample rate, and my version of Shoutcast expects 44100/16/2. There remains work to be done.