Broadcasting Your Audio: Part 1

A live stream from Big Brother.

Part one of a two‑part Net Notes in which Dave Shapton explores the theory and the practice of broadcasting your audio and video on the Internet. This is the first article in a two‑part series.

For me, one of the most exciting things that the Internet has to offer is the chance to broadcast stuff that I have written to the rest of the connected world. That's not to say that anyone would want to listen to it, but it would be nice to know that they could if they wanted to. On a less self‑promotional level, I know that many SOS readers either make a living from their creative efforts, or would very much like to. For them, streaming audio and video on the Internet is a fantastic opportunity.

Now it's easy if all you want to do is listen to music and watch video on the Internet. Just make sure you have a working connection to an ISP (Internet Service Provider) and a reasonably modern computer with a browser. But what happens if you actually want to put audio and video onto the Internet for others to hear and see?

The Problem Of Bandwidth

The Internet isn't like a radio or TV transmitter. It's more like a telephone network. The telephone network functions pretty well, but what it doesn't do is broadcast. The only way to broadcast on the telephone network would be to phone everyone simultaneously. Then, having answered the phone, anyone who wasn't interested in listening could hang up. Can you imagine how impractical — not to say annoying — that would be?

To understand what's involved in broadcasting on the Internet, you have to know a bit about the structure of the Internet, and how it works. The Internet is one of the most complicated man‑made structures every built but I'm going to deliberately avoid using too many FLAs (Four Letter Acronyms) and other technical jargon when explaining how it works. Even if you are completely non‑technical (and that's perfectly OK!), you may find some of this stuff useful in planning your Internet streaming ventures.

Ask almost anyone what the Internet is and they'll tell you that it's a worldwide network. Well, that's right. On a small scale, within a room or perhaps a department, a network is, in electrical terms, a buss. A buss is a device that connects a number of devices. What's more, any signal on the buss is available simultaneously to all the devices on it. It's a bit like a notice board. Pin an envelope on the board and everyone within sight of the board can look at it.

This type of network architecture would be ideal for broadcasting because, actually, everything is broadcast. But this type of network has a fatal flaw: it only works on a small scale. This is because every device on the network has to share the available data bandwidth. Since every bit of data is available to every device on the network (exactly what makes it great for broadcasting), you can by definition only send one piece of data at once. And that means that while any device is receiving data, all the other devices have to wait. The formula is actually very simple: you just divide total bandwidth of the network by the number of devices on it. So, if two people share the network, it'll go like the clappers. If 10 share it, it's probably OK. If 100 people use it at the same time, you'll be looking for another alternative. If millions use it, it will be as slow as a convention of slow things pretending to be statues.

Theory

Data rates during a live video streaming session.

However, the Internet does work, which means that it doesn't use a simple buss‑type network. The clue to how it works is in the name Internet itself. The Internet is actually a vast collection of inter‑connected networks. Data on the Internet gets to its destination by being routed through devices called, surprisingly, 'routers' (and you thought networks were difficult!).

Before we look closer at the mechanisms the Internet has for streaming audio and video, it's worth looking at how sound and pictures can be sent over a network in the first place. In some ways, you can treat digital media as if it were just data. If you are storing it, it sits on your hard disk in the same way a spreadsheet or database file would. It's just ones and zeros like any other digital information. And just like other data, it can be sent across a network.

Audio and video are a special case though — note that, for now, I'm not going to distinguish between streaming (which is when you see the contents of a file almost as soon as you select it) and downloading (which is what you do to MP3 files) where you have to have the whole file on your computer before you can listen to it. When you send data across a network, it's no good just sending the original ones and zeros. The device at the receiving end would just interpret them as a random sequence of bits. It would have no way of knowing what they meant and would have no idea whether they had all arrived or, indeed, when they had all arrived.

In practice, data is divided into manageable chunks, called 'packets'. These packets of data are individually numbered and every one has its destination address written on it. When a packet is put on the network, the routers look at the destination address, look up the position of the other routers on the network, and work out the best route to send the data. When the packets arrive at their destination, they are 'unwrapped' and re‑assembled as the original sequence of data.

This is very abstract. If you're finding this hard to get to grips with, think of a simple analogy: trains, in this case. To be specific, lets imagine that we have to get all the parts to build, for example, a power station, from one end of the country to the other. First, break the parts down into manageable sizes and label them. Then, put each pile of parts into a standard train carriage container. The containers fit onto freight train wagons that are coupled together and sent on their way. The train driver knows where he is going and arranges for all the points and intersections to direct him to the correct destination.

When the train arrives at the other end of its journey, the parts are taken off the wagons, out of the containers and, according to the way they are labelled, re‑assembled. It doesn't matter how big the device being transported. You can always use more wagons and more trains. Of course, you don't have to send everything by train. As long as every container has its destination address, you could send it by road as well. You could have 10 lorries, and they could all go a different way. It wouldn't matter because, as long as the containers get to the same address, the original structure can be reconstructed without any regard for how they actually got there. This facile and contrived analogy shows in a very superficial way how data is carried on the Internet.

Practice

So, what do you do if you want to stream a recording of audio or video to someone on the Internet? This may surprise you: you normally don't hold the files you want to stream on the same server as your web server. This is simply because the web server already has enough to do, without handling the amount of work that streaming audio and video can generate. Your web server may not actually be a physical machine and the chances are that it's running on one of your ISP's computers. A web server is actually a the program that does the serving — not to be confused with the computer that is running the server program).

To set up a file so that it can be chosen by and streamed to the user, you need to make a hyperlink on your web page, that is actually the URL (or address) of the file on your streaming server. As far as the user viewer or listener is concerned, the action of clicking on the link will have started the file streaming: they will have no sensation of being transferred to another server. We've seen earlier in this article that packets of data can take as many routes to their destination as there are packets, although this is unlikely. Anyway, the end result is what we might call a 'virtual connection'. Effectively, when you click on an HTML link, you make a connection with the web server. It's your connection and no‑one else can share it or listen in to it (unless they've got some sneaky 'packet‑sniffing' software). It's an efficient way to do things if you are the only user, or one of a small number. Most web and streaming servers can handle dozens of concurrent users without difficulty. For video‑on‑demand there is probably no better way to do it.

When your user base grows, the 'on demand' model gets less efficient, for several reasons. Each connection to the server demands processor time and a quantity of RAM. Web servers expecting large numbers of users need fast processors and vast amounts of RAM. And each connection potentially needs continuous access to the streaming file its user has selected. It's not a problem when there are only a few users because modern hard disks can easily handle the data rates. In fact, hard disk data rates are rarely a problem — but seek times are. The seek time is the delay in between a hard disk receiving a message to retrieve some data, and actually being in a position to collect it. Although hard drives normally have enough buffer memory to 'smooth out' the gaps, if you have too many users there are more gaps, due to the seek time, than there are periods when data is actually being retrieved from the drive. That's because each user will potentially be looking at a different file, or a different part of the same file. If you limit your Internet streaming aspirations to having a small number of users, then the chances are that you won't have these problems. But things start to get really interesting when you start to have more than one person looking at the same part of a streaming file at the same time, or when you want to stream a live event.

Find out more next month, when I'm going to talk about multicasting versus unicasting (they're both ways of delivering streaming content), and about how to best prepare your audio and video for broadcasting on the Internet. By the way, if you've read this far, congratulations on your newly earned status as an Internet geek. For your homework, go and learn how to slag off every operating system except Linux. (No, not really).