Background

During the Radio1:1 experiment, Berlin, June to August 2006, our team decided to build a broadcasting system that would cover our special needs. Please see the flyer for a quick overview.

As a programmer, the mayor difficulty I had to face was the lack of a player that could be controlled remotely through a standard protocol.
I finally settled for writing plug-ins for the Icecast streaming server (the result can be downloaded here)

While this worked as a temporary solution, it was apparent right from the start that we were missing a central component: a player that would take commands from a scheduler, do crossfades, switch to a life stream or streams from external sources, blend in the station jingle, do dynamic range compression, and then pipe the output to Icecast.

While Puredata is not the obvious choice for building such a player (see the "odd ends" section below), such an implementation can be an excellent prototype as well as a reference, and IMHO an interesting experiment.

Specification

1. Receive and send OSC commands, through UDP and / or TCP.
   // TODO : list of commands
2. Play ogg, mp3, wav files (at least).
3. Interpret scheduled commands: start / stop playing at a precise times
4. Do decent crossfades, fade-ins and -outs with adjustable functions.
5. Relay audio streams from the Internet, as well as life stream from the studio.
6. Create a stream that can be piped to an Icecast server. The stream should have a predetermined bitrate and format, independent of the format of the input files or streams.
7. Play the sound through a local soundcard for feedback. Stream and audio output should be concurrent.
8. Occasionally save the stream to disc.
9. Do dynamic range compression as well as normalizing.
10. Failsafe: if the connection to the scheduler is lost, the player should switch to its own playlist.

Odd ends

Quality loss through format conversion: in an ideal situation, all audio files in the archive will have the same format and bitrate. This is of course never the case, so format conversion is necessary, otherwise the buffer of the streaming server will occasionally become empty, and the connection will be lost. This was probably the most important lesson we learned from Radio1:1. Some kind of balance has to be found between audio quality, CPU load and bandwidth.

No authentication: authentication is not the responsibility of the player. Possible solutions include tunneling of TCP through SSH, bridging UDP to TCP and then tunneling.

Metadata: Puredata will not handle metadata. File metadata should be made available to the streaming server. This can probably be accomplished by a Puredata external, or another application.