One staple of daily life at the University of Delaware are the chimes which play on the hour from 8 a.m. through 5 p.m – the carillons. These “bells” have long been virtual: audio files purchased from a vendor and played through amplified speakers on building roofs. Yet even virtual bells age, and the aging hardware and software on which the chimes were being played was slated for replacement.
At the same time, the University desired to setup a system that would allow audio to be broadcast across campus in case of an emergency. The carillons, each being in essence a computer with large, amplified speakers attached to them, were a perfect candidate.
Those computer icons are no coincidence; the system is built using Mac Minis. The combination of Unix functionality (which fits well into our existing infrastructure) in such a small form-factor makes them wonderfully-suited to this particular application.
The old carillon system ran on old Sparc stations that sent pre-built PCM samples (loaded from a disk file) to /dev/audio to render audio. Under Mac OS X, the new system makes use of CoreAudio to load audio data from a variety of file types (MP3, AIF, WAV, etc) and render the audio at any output sampling-rate, volume level, and channel arrangement.
The project includes C/Objective-C code that implements utilities to render audio, build playlists (combine multiple component audio files into a single entity), and retrieve audio file information. The most important program, by far, is the carillon scheduler: it manages a priority queue containing recurring events and triggers them at the appropriate times. The hourly chiming of the carillons is one kind of event; other event types include the playback of a playlist and the execution of a program. The scheduler uses a cron-like syntax to specify the recurrance pattern of events and sleeps through any long periods of time that contain no activity to minimize CPU usage.
Deployed carillon slaves are rather simply configured: each runs an instance of the carillon scheduler program which initializes the event queue from an XML property list file. Each slave can have a customized XML property list to make it unique – in our case, the carillon and emergency volume levels are custom tailored. The web-configuration interface for the system also has the ability to restrict to which slaves any event should apply.
All transactions across the network are made through SSH, using a passwordless key. The system is secured by enabling the software firewall on each machine and only opening port 22 (and HTTP/HTTPS ports on the master).