I’m just nuts about automation, and probably many other engineers are too. I find it deeply satisfying to watch machinery perform a programmed routine I’ve created. This may stem from the feeling of power over the inanimate.
We’re not speaking about word processing macros here, but the kind of automation that can read transmitter logs, play audio files, command switchers and call you at home when there’s a problem.
Usually teams of people write, test and debug these automation products and armies of marketing folk barrage the industry with colorful brochures and multidigit pricelists.
But in this case, I was an army of one, writing a little piece of software that played audio files for NPR’s online services. The project turned into an application that eventually became available to all NPR member stations.
What’s the combination?
The story began in the cold blustery months of 1999.
I was tasked with taking two HP Vectra tower computers and building them into Linux servers, replete with e-mail, modem, FTP and HTTP services. These servers were to become “Armstrong” and “Fessenden” – the main intake points for reporters sending audio files to NPR.
I didn’t know spit about Linux, or Unix for that matter, and was having a time stuffing my brain with the arcane notions of this super-fine operating system.
The NPR Webmaster at the time, Robert Holt, encountered his own challenges. He had to develop a flexible audio file playback scheme, under deadline, so that NPR could join the Internet audio-streaming crowd.
Rob found the existing applications for scheduled playback to be too limiting, too proprietary or too expensive. He wanted to use a rapid-application-deployment programming language like Microsoft’s Visual Basic, but didn’t have time to learn fully the nuances to make the project materialize under his deadline.
One afternoon we happened to be hanging around his office, moaning our fates, when the idea struck. Why not switch tasks with each other?
Rob knew Linux/Unix, I knew Visual Basic. When our management agreed, we set about our respective tasks.
My obsession about automation came into play. In the early 1990s, I developed an application that automated the transport control of 36 tape recorders, ostensibly for a university media department.
The system was a sweet, tight application, compiled in QuickBasic 4.5, that ran under DOS. Although this application never went anywhere, the source code was invaluable for reuse in the automated player project.
I made up a working title for the project – AudioLocker. The name is an homage to Broadcast Electronics’ venerable AudioVault, which, although robust and ready to go, wasn’t suitable for this application at that time. BE has since enhanced its product line to make AudioVault accessories do the things AudioLocker was designed to do.
Before writing any Visual Basic code, Rob and I developed an extensive set of rules and qualifications that AudioLocker had to meet – essentially, we wrote the help file first. This keeps one’s sanity and focus.
NPR’s Online Division already recorded “All Things Considered,” “Morning Edition,” “Talk of the Nation” and “Weekend Edition” as standard .WAV files – at least one audio file per hour – for conversion to RealAudio, so we planned on supporting .WAV and other popular audio file formats.
With this requirement in place, our job was to create the concept of “groups of files” so that Internet listeners could hear the entire program, one file played after another. The files would have a programmed day and time-of-day “window” where the files within the group would be played.
With a working set of rules in place, I began to build AudioLocker by component parts. Those details will appear in the next Public Domain.
Rules of the AudioLocker
The rules for creating and operating the AudioLocker were important to our understanding of what direction we were to undertake. The following is the outline of the rules we’ve created.
1. Operations
A. The system plays groups of audio files during certain times of day. The files within a group are played in sequence until that group’s “end time” is reached or exceeded.
B. The audio files are of any length because they are cut-down versions of NPR programs. The files can be uncompressed .WAV, .AIFF, .MP2 and other files supported by the Microsoft ActiveMovie Control, version 2.0.
C. AudioLocker does not “fill time” to pad a file’s length to an hour or half-hour, but rather, AudioLocker continues to play the files within a group, in sequence, until that group’s end time is reached or exceeded.
D. A group will not start playing any sooner than its “start time” and no later than the longest audio file in the previous group – minus one second. For example, if a group’s end time is 13:59:59 and a file within that group ends at 13:59:59, another file within that group will play. After that file finishes, a new group will be loaded and the first available file in the new group will play.
E. AudioLocker is day-sensitive and supports overnight services whenever a group is programmed to play past midnight.
F. All activity is printed to a log.
G. A manual control panel is available by menu and gives the user the power to force the next event to interrupt the current file immediately and to “insert” a file of the user’s choosing as a “one-time” event. The inserted file, if available, will play after the current file ends, and only will play once. The AudioLocker playlist resumes after the inserted file finishes.
H. AudioLocker is fault-tolerant of missing or unavailable audio files, and simply skips over the unavailable file. This file will be played, if it becomes available, after the other valid files in the group have been played.
I. If a group has no valid files at all, a file called emergency.wav will play until that group’s end time is reached or exceeded.
J. If a gap in the schedule exists where no files were schedule to play, AudioLocker will continue to play the previous group. If AudioLocker was started during this schedule gap, the emergency.wav file will play until a group is found which has a start time equal to or earlier than the present time of day.
K. Schedules can be written with any plain-text word processor, and loaded into AudioLocker’s database in one of the following ways
1. Before AudioLocker starts by using the “load” command line parameter.
2. After the current file finishes playing.
3. After the current group’s End Time is reached or exceeded.
4. Or, the user may cancel the file load, and restore the previous schedule.
L. A copy of the database can be saved as a plain-text file – menu: File | Save Schedule As –, which is suitable for editing and/or reloading at a later date.
M. The plain-text schedule may include comments prefaced with a single apostrophe (‘) as the first character on the line
N. The minimum number of files in any group: one. Maximum number: currently limited to 1,024.
2. Limitations
A. 1,024 lines of schedule can be displayed and setting MAX_ARRAY to the desired number, and recompiling the program can overcome this limitation.
B. There is no practical limitation to the number of lines in the database.
C. As of version 1.16, there is no provision for repairing the database or compacting the database from within AudioLocker.
D. Schedules are not checked for correct timings, group overlaps, or other problems, only for correct syntax.
E. AudioLocker does not check the predicted “next event” time with the time-of-day when a file stops; it simply plays the next event as calculated when the original file started playing. If a file is stopped or paused for any appreciable amount of time, then allowed to finish, the next event file will be played, regardless of the group’s end time being reached or exceeded.
