Technical Background:

In early 1998, the Faculty of Media, Music and Performance of Salford University bought and installed an entry-level web server (Silicon Graphics Challenge S) to complement the main university web server and to provide services to faculty members that were not available through the latter. A major service that we wished to offer was the possibility of both audio and video streaming of files. As opposed to only being able to listen to an audio/video clip once it has completed its download from the Internet, streaming technology enables the end-user to listen to the clip as it downloads regardless of whether they wish to listen to a static file or a live bitcast. To this end, the Faculty purchased Progressive Networks’ (www.realaudio.com) Real Audio Server which allows for multiple simultaneous listeners. Assuming both the server (bitcaster) and client (end-user) are connected to the Internet through their desktop computers, two other pieces of free software from Progressive Networks are required for the bitcast; the player and the encoder. The player is used by the end-user to listen to the real audio bitcast (or static file); the encoder requires more explanation.

The encoder is usually installed on a desktop computer (in our case we utilise Wintel PCs) and takes audio that is input to the computer’s sound card, or is played from the computer’s CD player or is a file on one of the computer’s disk drives. It then encodes that audio in one of several Real Audio formats (the process with video is much the same). During the encoding process much of the audio information is compressed or discarded in order to reduce the bandwidth of the resulting audio file and consequently the quality of the audio suffers drastically. This bandwidth (speed) can range from about 300Kbps (Kilobits/second) down to 8Kbps and there are various options (working mainly on frequency) that attempt to optimise the result for voice only, music and voice, or music only.

Consider this, in order to bitcast compact disc quality stereo music, the network (including receiving devices such as modems) through which it is sent must have a bandwidth that is never less than approximately 1.4Mbps (Megabits/second). The fastest publicly available modems have speeds of 56Kbps and many modem users will be using modems that are of lower speeds than this (such as 28.8Kbps). This is the first problem, one of bottlenecks in the network: your transmission speed is only at least as good as the lowest bandwidth point in the network. In other words, the bitcaster cannot expect their modem-based listeners to have much success when they attempt to bitcast CD-quality music. The newest generation of Real Audio Encoders and Servers are able to encode simultaneously at different bandwidths and sense what bandwidth the player is listening on in order to deliver a more reliable stream. In order to accommodate modem users, Boom Booom Net Radio encodes at approximately 22Kbps.

For the Real Audio bitcast to be available to listeners, it must be sent via a network to the Real Audio Server. When bitcasts take place from within the Faculty, a stable ATM (Asynchronous Transfer Mode) network of 155Mbps is used to reach the server, although the encoding PC’s network card has a bandwidth of 10Mbps. For location bitcasts (see below) a Demon network is used, limited by the 56Kbps modem attached to the PC, hence the encoding compression required must not only take account of end-users’ networks but also the encoder’s network.

Naturally, as we’re talking of networks (specifically the Internet), the Real Audio player does not connect directly to the Real Audio Server (nor the encoder to the server); the audio signal must travel through several computers - 'routing through hosts' in Internet parlance. Each of these host-to-host connections (or hops) will add time overheads to the signal (in addition to the computer processing time necessary to encode the audio signal before it can be routed to the server) and may traverse wide geographical areas. Consequently, there can be a considerable delay between the encoding computer and the listener’s computer.

In addition, and although the Internet structure attempts to compensate for this, various hosts in the route may have connection and/or congestion problems which in extreme cases can lead to the Real Audio player experiencing drop-outs which are manifested by either silence or wide-band noise.

As an example, in April 1998, the Faculty’s Music Department bitcast at 22Kbps a conference on Popular Music & Technology and one of the authors of this article was working at a university in Durban South Africa attempting to listen to the conference. The conference was held on a Friday and a Saturday; on the Friday, reception was so poor as to be worthless due to network congestion, mainly caused by the number of users utilising Natal University’s Dual ISDN 112Kbps network. On the Saturday (when presumably students have better things to do), the reception was excellent. In both cases, the delay was around 5 seconds.

Fig. 2

Boom Booom Net Radio:

This process allowed Boom Booom to extend their scope from monthly nights into twice weekly Internet broadcasts. With a laptop Wintel PC and a 56Kbps modem, the people involved would meet at each other's houses on Sunday evenings and the DJ's would practise their art whilst the world listened - we hoped.

Although we experienced network connection problems from time to time, all in all this proved to be a technical success. The Wednesday broadcasts were done through Salford University's ATM broadband network (although still encoding at approximately 22Kbps), which allowed for much greater stability in the path between the encoder and the server, creating a rock-solid output stream. We slowly watched an audience build up over time, via a Java applet (a web browser application), that allows the Real Audio server administrators to monitor the number of current listeners, and via various text-file logs that the server stores for all listeners.

The next stage was to introduce Internet Relay Chat to the process. IRC allows participants to chat in real-time within a text-based interface on a particular chat channel. In this way, listeners had the opportunity to give feedback to the DJ's and chat with other listeners or members of the Boom Booom team. This interaction between the music producers and the consumers meant that it was possible for the producers to establish a rapport with an 'audience', and for the audience to feel more involved in the whole musical experience. It was, in short, a way of creating more of a community atmosphere than is often possible with conventional media such as radio and TV. In addition, the audience chatting with us on IRC were also able to provide feedback on the technical/network issues, relaying to us any problems they were experiencing as they happened.

A further step was taken when Boom Booom started bitcasting the live events. The emphasis here was slightly different as they were 8-hour broadcasts, and we wanted to try and capture some of the atmosphere of the club. We had two rooms, each with different music, and took an audio feed from each room into a mixer and then into the PC. This allowed us to choose which room's music to broadcast at any particular moment. Additionally, we took a feed from the video mixer into a video capture card in the PC. Both the audio and video inputs were encoded as a live file, sent down the telephone line to the server at the university, and from there it was available to the rest of the world. This enabled people to watch the video projections that were being used on-site, whilst they listened to the live music.

Although the live events attracted quite a few listeners, it became clear that an Internet audience can be frustratingly elusive. We started publicising the live events, as well as the twice-weekly broadcasts, submitting them to web-based channel listings and submissions engines such as Timecast (www.timecast.com) , Audionet (www.audionet.com) and Yahoo (www.yahoo.com). This proved useful in helping to build up the listener base.

Another development was Java chat as opposed to IRC. It became clear that not enough people were actually taking the time to chat with us and we decided that this was because it was too much effort to download a separate IRC client, install it, log on, find the channel, and then start chatting, in addition to using a web browser and Real Audio player on the same computer. The solution was to use a Java applet to allow us to embed a chat engine into the actual web page, which meant that the listener only had to load the web browser in order to be able to log on to the chat channel. Thus, more people were willing to join in the online chat.

With all these processes, problems arose at the encoding end due to the amount of processing that we required of the PC. Simultaneous encoding, running of the Java server monitor, the Java chat and sending and receiving via the modem, all on one PC is precarious, to say the least, and computer crashes at Boom Booom events are rather frequent, leading to frustrated consumers and producers. The solution would have been to have two computers attached via modems to different telephone lines and dedicate one to just the encoding of the audio and video signals. Unfortunately, although many venues may have more than one telephone line, they naturally prefer to reserve one for its proper purpose.

Fig. 3

Tracing route to hexie.memtech.salford.ac.uk [146.87.216.80] over a maximum of 30 hops:

Fig. 4

Tracing route to hexie.memtech.salford.ac.uk [146.87.216.80] over a maximum of 30 hops:

1 2892 ms 133 ms 162 ms gyle-87.access.demon.net [194.159.254.87]
2 2608 ms 2447 ms 1511 ms tele-core-1-ge025.router.demon.net [194.159.254.100]
3 155 ms 140 ms 147 ms tele-border-1-fxp0.router.demon.net [194.159.252.252]
4 146 ms 146 ms 1816 ms gw.linx.ja.net [195.66.224.15]
5 3016 ms 2902 ms 2932 ms south-east-gw.ja.net [128.86.1.50]
6 2716 ms 636 ms 153 ms manchester-core.ja.net [146.97.253.62]
7 2838 ms 2549 ms 1502 ms gw-mcc.g-ming.net.uk [146.97.253.118]
8 1918 ms 2070 ms 1789 ms gw-peel.g-ming.net.uk [194.66.23.5]
9 2922 ms 3044 ms * hexie.memtech.salford.ac.uk [146.87.216.80]
10 978 ms 1246 ms 1173 ms hexie.memtech.salford.ac.uk [146.87.216.80]

 

Boom Booom bitcasting utilises modest technology, especially when making use of modems for the live bitcasts, and the following conclusions may not hold for other bitcasters. However, regardless of the organisation and level of funding, public bitcasters have no control over possible bottlenecks between server and end-user.

It is quite obvious that theory often exceeds practice. This is a result of the modest technology that is utilised by Boom Booom and the desire to provide a full variety of services to their audience; hence the frequent computer crashes at live events.

Despite frustrations caused by network congestion, drop-out, computer crashes and so on, audiences are remarkably patient. They perhaps understand that bitcasting technology is still in its infancy, and it may be that there is a novelty value attached to such bitcasts. Likewise, bitcasting - as in Boom Booom’s case - seems to have found or created an audience for events that would not normally be broadcast on other forms of media. Additionally, providing chat pages, as a form of interaction between consumers and producers, helps create a loyal audience who feel a part of the events.

Glossary: