MAT 201B / CS 290I--Media Networks and Services
Homework Assignment #3
Due BEFORE CLASS STARTS on Tuesday, December 4, 2001

1.0 Assignment Overview

Dealing with audio across a network is an interesting problem. This assignment deals with two aspects: actually sending streaming audio across the network, and studying the effects of losing some of the packets. While the two are obviously connected, they do not necessarily need to be implemented together. Therefore, this assignment will have two parts. While it is theoretically possible to use the code from the first part to conduct the study in the second part, it will be much easier to simulate the effects of network transmission without actually sending data over the network.

In the first part of the assignment you will write a client and a server to send and receive audio packets. However, you will not need to turn in your server, just the client. To help you test your client code in a way identical to how we will test your client when grading the assignment, we will provide you with an executable version of a server at some point before the assignment is due. Setting up the assignment this way achieves a secondary objective: understanding that writing a client and server is much more difficult when you are developing software to implement a written specification!

2.0 Assignment Background

Figure 1 shows a typical architecture over which real-time audio packets might flow. Handling real-time audio traffic in such an environment is non-trivial for two reasons. First, the data being transmitted is assumed to be real-time; therefore, minimizing delay is crucial. Second, the network can introduce a certain amount of jitter which must be compensated for at the receiver. If a packet is delayed long enough, it does not reach the receiver by the time it needs to be played out. If this happens, the packet is useless to the receiver, and will be discarded.

For this type of real-time operation, and for this assignment, you can assume that if the jitter causes a packet to arrive after its playback time, then the packet is lost. Since the probability of losing a packet is non-zero, the receiver must have some policy for handling playout when some packets arrive after their playback time. You will experiment with some of these different policies.

Packets can also be lost because they arrive too quickly from the transmitter; the receiver's buffer fills up; and packets must be dropped. One way to solve this problem is to create additional space in the buffer by further compressing the audio data already in the buffer. You will experiment with different mechanisms for compressing mu-law encoded data.

3.0 Assignment Details

3.1 Streaming Audio Client

Your client code works in conjunction with server code. However, since you do not have to turn in your server code, the only requirement of the server is that it interacts correctly with the client. An executable version of the server code will be made available shortly. In the meantime, you should consider writing your own. Your client should run with the following interface: ----------------------------------------------------------------------------- -----------------------------------------------------------------------------


Sample session:
----------------------------------------------------------------------------- -----------------------------------------------------------------------------

Other notes:

3.2 Analysis of Effects of Packet Loss

3.2.1 Simulation Model

In the second part of the assignment, you will not have to transmit packets over a network. One way to simulate the network is to create one procedure to transmit packets, and one procedure to receive packets. You can pass the packets between the transmitting procedure and the receiving procedure any way you want. One way might be to pass a C pointer to a data structure. (NOTE: You do not have to turn in code for the second part of the assignment. Therefore, you can write the code in any language you wish; examples are obviously given for C.) You must also find a way to introduce jitter into the flow of packets from the receiver to the transmitter. One way to simulate jitter, i.e. packets arriving after their playback point, is to not deliver the packet. In your simulation, this means the packet will not be passed to the receive procedure. The receiver assumes it was lost; or arrived after the playback point, and discards the packet. The main procedure in your code should be simple. It only has to open the devices, and then start a loop to send and receive packets until there is no more sample data. The main procedure in your code might look like the following:

   while not EOF {
      read_sample();   /* Read audio sample from a file */
      play_sample();   /* Play out the received sample */

3.2.2 Writing Your Simulator

The single hardest part of this entire assignment will be finding a machine to conduct these experiments on. The hardest part will be finding a machine that has: (1) speakers and a working audio card, AND (2) a Java or C compiler. HINT: Find such a machine early... like as in now.

The second hardest part of this assignment is dealing with the audio format. You can make your life hard by choosing a complicated encoding and compression algorithm. You can make your life easy by choosing mu-law encoding which is the basic, uncompressed format that Sun uses in its *.au files. The challenge here is to find tools that can read and play these files.

To help you get through some of these problems, there is some C code in Section to help you with device and file processing, and a location of some *.au files in Section Device/File Processing
You may or may not know how to write the code to open the audio socket, and the audio data file. Since this is an implementation issue, we are providing help on the commands and syntax for opening the audio device and sample files.

To open the audio socket, use the following statement:

audio_device_ID = open("/dev/audio",O_WRONLY | O_NDELAY);

To open a file containing sample data, use the following statement:

source_file_ID = open("",O_RDONLY | O_NDELAY);

The return value of the ``open'' function is an integer that serves as the identifier for the opened device. For more information, do a ``man open''. Once the device or file is open, you can read or write using the ``read'' and ``write'' commands. Both statements have the same format, and look like the following:

return_code = read(device_identifier,buffer_variable,length);

The ``device_identifier'' is what is returned from an open command. The ``buffer_variable'' is the array used to store read data, or as a source for write data. The length specifies how long the data to be read or written is. For more information on the read or write statement, do a ``man 2v read'' or ``man 2v write''. Sample Files
The audio data that we will be using is mu-law encoded. Part of your assignment will be to understand this encoding technique. Basically, each sample is an 8 bit non-linear value which is obtained by sampling the audio source 8000 times a second.

To help you get started, we have provided some sample audio files that you can use. These are located in the samples directory.

You can also play out any sample file, or record your own samples using the programs ``audiotool'', or ``soundtool''. In order to create your own sample files, you'll need a microphone.

3.2.2 Experiments

Your objective is to experiment with several of the parameters that affect audio quality. Using the network model discussed earlier, you will simulate a network which delivers audio packets with any level of reliability. For each parameter, you must first decide the range of values to be tested. This range should include enough points to demonstrate the affect of a parameter on audio quality. Furthermore, you should test the affects of changing these parameters on different types of audio sources, i.e. voice, music, etc. The parameters you should experiment with include the following:

4.0 Deliverables

For this project, there are two deliverables: