Mark Grimshaw; Louisa Yong; Ian Dobie

"Boom Booom Net Radio"

The International Journal of Urban Labour and Leisure, 1(1) <>

ISSN: 1465-1270


Internet radio is one of the growth areas of the Internet but, as this article will show, is fraught with difficulties and frustration for both the modestly-funded broadcaster (bitcaster) and the listener. The article will illustrate some of these problems by means of a short case study of an existing Internet radio station; Boom Booom Net Radio ( Whilst necessity dictates some use of technology-related terminology, wherever possible we have endeavoured to keep such jargon to a minimum and to either explain it in the text or to provide further explanation in the appended glossary.

rollerline.gif (636 bytes)

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’ ( 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. 1 shows the results of a ‘ping’ from a desktop PC in Salford University to Natal University’s web server ( while Fig. 2 shows the results of a ‘traceroute’ between the same two computers (both taken after the event):

Fig. 1

Pinging [] with 48 data bytes
Statistics for
5 packets transmitted, 3 packets received, 40% packet loss
round-trip (ms) min/avg/max = 2203/2409/2663


Fig. 2

traceroute to (, 30 hops max, 40 byte packets
1 ( 2 ms 2 ms 3 ms
2 ( 10 ms 14 ms 11 ms
3 ( 24 ms 21 ms 14 ms
4 ( 26 ms 29 ms 33 ms
5 ( 27 ms 28 ms 35 ms
6 ( 130 ms 136 ms 122 ms
7 ( 168 ms * 152 ms
8 ( 170 ms 188 ms 295 ms
9 ( 187 ms 181 ms *
10 ( 253 ms 193 ms *
11 ( 183 ms 265 ms 189 ms
12 * * ( 213 ms
13 ( 198 ms 198 ms *
14 ( 240 ms 194 ms 185 ms
15 ( 197 ms 281 ms *
16 * ( 201 ms *
17 * * *
18 ( 4994 ms * 4636 ms
19 * * ( 5377 ms
20 * * *
21 ( 5133 ms * *
22 * * *
23 ( 6835 ms * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * ( 7607 ms

As will be noticed, both figures show that the connections were not always successful (which may or may not manifest itself in problems for the Real Audio player were this to be an audio signal we were attempting to bitcast), although the structure of the Internet usually means that we will eventually reach the destination host. Each asterisk in Fig. 2 indicates a failure to reach the host - there are usually three attempts per host. Fig. 2 also shows that for an Internet signal to travel from the UK to South Africa it must first travel to the USA where routers such as Teleglobe and AT&T pass it to the final destination.

Boom Booom Net Radio:

Boom Booom is a collective that runs events once a month at a sited venue in Manchester. It is run by a group of DJ's, sound engineers and media practitioners who combine to form a safe and interesting mixed-media experience for the discerning club-goer. The venue is filled with hand-made décor, video projections, lightshows, strange paraphernalia, and loud, pumping dance music. Boom Booom has been on the Internet for some time, maintaining its own web-site in a modest fashion for several years, providing information on bands and DJ's, forthcoming events and a large section which provides links to other members of the Netted Musical Underground. Since then, however, Boom Booom's Internet presence has grown with regular forays into bitcasting. This happened at a time when Salford University's Music Department had access to its own web server, as well as purchasing a Real Audio server. Some members of the Boom Booom team worked at Salford University and were instrumental in setting up the Real Audio server software on their web server.

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 ( , Audionet ( and Yahoo ( 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 shows the results of a modem-based PC ‘traceroute’ through to the Real Audio server while Fig. 4. shows the results of a modem-based ‘traceroute’ from the encoding PC to the Real Audio server (both were taken during an actual broadcast on a Sunday between 19.00 and 21.00 GMT):

Fig. 3

Tracing route to [] over a maximum of 30 hops:

1 313 ms 150 ms 145 ms []
2 270 ms 365 ms 273 ms []
3 336 ms 235 ms 157 ms []
4 157 ms 160 ms 160 ms []
5 158 ms 187 ms 159 ms []
6 169 ms 165 ms 179 ms []
7 195 ms 180 ms 178 ms []
8 178 ms 173 ms 174 ms []
9 174 ms 175 ms 174 ms []


Fig. 4

Tracing route to [] over a maximum of 30 hops:

1 2892 ms 133 ms 162 ms []
2 2608 ms 2447 ms 1511 ms []
3 155 ms 140 ms 147 ms []
4 146 ms 146 ms 1816 ms []
5 3016 ms 2902 ms 2932 ms []
6 2716 ms 636 ms 153 ms []
7 2838 ms 2549 ms 1502 ms []
8 1918 ms 2070 ms 1789 ms []
9 2922 ms 3044 ms * []
10 978 ms 1246 ms 1173 ms []



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.

It may seem that the problems enumerated here far outweigh the advantages. Whilst it is true that modestly-funded groups such as Boom Booom will encounter most if not all of these problems, larger organisations, like major Radio and TV networks, are able to overcome them with more sophisticated and expensive technology. For the smaller organisations though, bitcasting can provide valuable access to a global audience, for a relatively low cost, in what is, still, a largely unregulated arena.


ATM Asynchronous Transfer Mode. A broadband computer network with a bandwidth of 155Mbps.
Bandwidth The maximum number of bits per second that can be transmitted or received over a network.
Bit Contraction of binary digit. The smallest unit of digital data existing as either a 1 bit or a 0 bit (binary)
Bitcast An Internet broadcast in real-time – analogous to a radio or TV transmission.
Byte A group of 8 bits. One character (for example ‘a’) is usually encoded within a byte.
Client Usually referring to a computer within a network that accesses data on another computer although, more correctly, the software on that host which accesses that data.
Demon An ISP (see below).
Downloading The process of getting a file from another computer via a computer network.
Host A computer participating in a network.
Internet A global collection of interconnected computer networks.
IP address Internet Protocol address. A unique network address for a host. Analogous to a postal address. The IP address of is
ISDN Integrated Services Digital Network. A computer network with a bandwidth of 64Kbps.
ISP Internet Service Provider. An organisation that provides Internet access to other organisations or individuals.
Java applet Computer software written in Java code and that can be interpreted by a java-capable web browser on most modern PCs.
Kbps Kilobits (1000 bits) per second. A measurement of a computer network’s (or part thereof) bandwidth.
live file Refers to the data in a bitcast as opposed to a static file that is stored on a computer.
Mbps Megabits (1000000 bits) per second. A measurement of a computer network’s (or part thereof) bandwidth.
Network A collection of interconnected computers. The Internet is a network.
Ping Software that performs a quick check on the viability of a computer network and the status or accessibility via the network of the destination host.
Server Usually referring to a computer within a network that provides data although, more correctly, is the software on that host that provides or serves that data to a client.
Static file A computer file such as an audio file that is stored on a computer or removable media such as a floppy disk.
Streaming The process of either bitcasting or playing a media static file as it downloads.
Traceroute Software that displays information relating to the network path between two hosts on a computer network.
Wintel A contraction of Windows and Intel and referring to a PC that has a Windows operating system and an Intel (or similar) processor.


Mark Grimshaw Mark Grimshaw teaches Music Technology & Studio Production in the Music Department of Salford University. With a BMus(Hons) from Natal University, South Africa and a MSc Music Technology from York University, he worked as a sound engineer in Italy before taking up his current position. He writes articles on music technology and African music in addition to recording and production work. He can be contacted at:
Louisa Yong has been a freelance webpages designer since 1992 when she was still a music student in the University of Hong Kong. After she completed the Music Technology MSc degree at the University of York in 1996, she received a 3-year PhD studentship from the University of Salford to research and develop music applications on the Internet. Louisa's current research project is on the Composers Experimental Online Suite (ComeXos). The aims of ComeXos are to provide a graphical interface for accessing the Composers Desktop Project (CDP), a sound manipulation package, via the Internet in order to create and share audio samples. The research also investigates the economic, sociological and educational impacts of such a project. She can be contacted at:
Ian Dobie
graduated from Salford University in 1998, having specialised in Music Technology and Studio Production, and is currently doing a PhD at Salford University. He is undertaking research into the creative, social, technical and commercial aspects of broadcasting and streaming audio on the Internet. He can be contacted at

back.gif (518 bytes) fwd.gif (593 bytes)

rollerline.gif (636 bytes)

IJULL Last Updated: © 1999-2007 International Journal of Urban Labour and Leisure