Alluvium - Technical Overview

The first thing you need to run an Alluvium station is a playlist. This is a simple file in the Alluvium playlist format, which is based on the RSS 1.0 news format. All of the RSS tags used are standard tags from existing schemas and which retain their intended semantics. Radio station playlists and RSS newsfeeds are really quite similar. They both specify a sequence of content of possible interest to the audience. One interesting side project to do would be creating audio and video weblogs and news stations which are created by aggregating multimedia feeds about particular topics. For the moment, however, we're working on simple music and voice broadcast. You can generate an Alluvium playlist file easily from a normal music play playlist file using the playlist generation tool.

The playlist file specifies the locations of a series of files containing content and also the time at which that song starts. The client software will skip through the playlist until it finds the song which is scheduled for the current time and then fetch that song. The files are specified as URLs and so can be hosted anywhere on the web. Each file could even be hosted on a different site. Most importantly, the files don't have to be hosted on the same site as the playlist.

Files are downloaded using the Open Content Network (OCN) utilizing exciting swarming download technology. The client software first checks with the OCN gateway, which stores special headers for all of the files being distributed through the OCN. If the gateway doesn't know about a particular URL, it will fetch the necessary information from the URL and then cache it. The information stored by the gateway contains information needed to swarm download the file such as a hashtree.

Among the information obtained by the client from the gateway is a list of addresses for other clients who are also downloading or have recently download the file. Clients download multiple parts of the file simultaneously from each other. When a certain part of the file is unavailable from other clients, a client will fetch it from the original source URL and then share than part with the other clients, minimizing the load on the server which stores the content files. The majority of data transfer happens between peers. Additionally, priority for downloading is given to chunks earlier in the file. This means that while the file does geneally transfer out of order, it is sequential enough for file playback to happen immediately.

After the first file download has started, the client immediately starts sending it to a locally generated icecast-compatible stream. You can then direct your media player to the local stream and listen to it exactly as though it was a normal icecast stream.

The benefits of this technology are savings in bandwidth and processor usage. Since most downloads happen between listeners, the server has much less load. In fact, it is unlikely that an Alluvium station would ever have performance as bad as the icecast model, in which the server has to send every byte to every listener. Bandwidth savings are almost certain. Additionally, unlike icecast servers serving files for Alluvium stations have no need to decode the files. Therefore, you do not need to consume processing power decoding compressed music files. In fact, you don't even need a floating point processor. Alluvium broadcasts can be done from incredibly low-cost, obsolete hardware as long as they have sufficiently fast I/O and network speeds.