Introduction

MacMix was developed at IRCAM, a contemporary music institute in Paris. Musicians are interested in using computers to synthesise, analyse and modify sounds. The process of mixing or blending separate sounds together is fundamental and very common in musical production of all sorts.

Most of the difficulties we face with using computers to manipulate sound stem from a simple fact: we do not have a very compact digital representation of sound. We need roughly 1Mbyte of space to store 10 seconds of hi-fi quality sound. IRCAM has several Gigabytes of on-line disk storage and a large library of sound on disk packs and magnetic tape.

Most installations with this amount of data to store and process have found that a few, very large, centralised systems are more cost effective than a network of distributed workstations. This may change in the next few years, but musicians seek tools today and they are seduced by convenience and efficacity of mouse-graphic based workstations. MacMix attempts to give a musician the control they seek over sound stored on a centralised system shared by other musicians. The architecture chosen was to use a popular mouse-graphics computer for the user interface and have it talk over a network to IRCAM's large sound file host computer.

There are many such small computers to choose from. We chose the Macintosh because it is physically small, reliable, fairly cheap and has no noisy fan. Fan noise is inconvenient in recording studios. It would have perhaps been easier to use a UNIX workstation, since sounds at IRCAM are stored on large UNIX systems and off-the-shelf solutions exist for UNIX to UNIX communication problems. However, we will see that the network requirements of MacMix are not very cost-effectively served by such solutions.

The User is in Control

Users should feel that they are in control of MacMix and that services requested from the host result from their gestures. This requirement led to the single most important feature of the communication protocol between Macintosh and host: the Macintosh is always the master, the host is a slave.

The Macintosh sends requests for service to the host and waits for one of three kinds of responses: request serviced, request not serviced, and no response at all. The slave host computer only sends messages to the Macintosh in response to a request. It cannot request service from the Macintosh.

Stateless Server

The second requirement of the protocol is derived from the observation that the host is not to be trusted. The host should not be trusted because it is less reliable than the Macintosh and it is not under the control of the user. It need not even be in the same building or country as the Macintosh.

If the host can not be trusted, MacMix has to behave coherently when requests are not serviced and when the host fails to respond. It should also not be too sensitive to errors resulting from a host claiming it performed a service when it actually did not. These observations lead to the use of a stateless server on the host. If the host cannot be trusted, we should not assume that it can remember anything of early requests. This means that each request from the Macintosh has to include all the information needed for it to be completed by the host.

An example of state stored in the Macintosh which could have been stored on the host is the current directory. All file names sent from the Macintosh are also sent with a directory path. Directories are managed by the Macintosh even though their contents exist on the host.

Performance

In the long term MacMix uses very little of the available network bandwidth. This is because much of what the user is doing is provided for on the Macintosh. Every few seconds MacMix will issue a request for the contents of a directory or a few hundred samples in a sound file. The performance problem is that the user will be twiddling their thumbs as soon as the request is sent and will not stop twiddling until something changes on the screen in function of the hosts reply to the request. In other words latency is far more important than bandwidth in this application.

This can be contrasted with networks used for moving files and mail from system to system. In these applications delays of minutes to hours may be acceptable, but there may be a large amount of data involved. MacMix requests are rarely longer than a 100 characters and replies rarely more than a few thousand characters.

Implementation

MacMix has been successfully used with a very simple communication protocol running on RS232 communication lines at 19,200 Baud. The protocol is simple because we made the seemingly rash assumption that our communication lines were error free. The protocol has no error-correction. It has poor error detection facilities, but error recovery is very good since the Macintosh is so suspicious of the host. .P The assumption of error free lines is a good one, if the lines are installed correctly and operate over short distances. We have only observed one kind of error resulting from use of these lines: total failure. These errors occur for silly reasons: the cable is pulled from back of the Macintosh, someone accidentally unpatches the cable at the host, or rats eat through the cable. Whatever the cause, no amount of clever error-correcting will repair the cable.

What if we wanted to run MacMix remotely? In France it is cheaper to use a national packet-switching network to access IRCAM than to use modems. This network provides error-free transmission. In the USA it would be necessary to use error-correcting modems. We do not feel that this is a serious limitation as conventional 1200 baud modems are too slow for this application.

Improvements

Several tools would have made implementation easier and more powerful. It is surprising that UNIX is not already supplied with a protocol similar to the one we devised. Many sites use UNIX to down or up load data to other systems.

UNIX System V comes with the xt driver, which is used to communicate with software in the DMD terminal. Their protocol appears to be useful in applications like MacMix, but has not been published. Its main feature is that it multiplexes several channels on a single RS232 communication line. If this was available MacMix could control several host computers simultaneously, or users could interact with several UNIX processes at once on a single Macintosh.

We use XON/XOFF flow control in both directions to avoid overflowing input buffers in the Macintosh and UNIX host. The UNIX host we are using, like many available, finds it buffers overflowing far more often than necessary. These systems cope with data rates from disks at least 10 times than those from serial ports. The latest generation of UNIX machines do not appear to have this problem.

The MacMix server process is structured much like a UNIX shell. It parses a request. If the request makes sense it checks to see if another process is required to perform the request. If there is it handles communication with that process. If not it fulfills the request directly. Why not use the shell? Why did we create our own server process? The problem with the shell is that there is no easy way a program can parse its output and the output of the programs it executes. This output was designed for human consumption. There is a also a performance problem, as the shell spawns new processes for each user request. Our implementation spawns a single process for each service required and communicates directly to these processes. There is no overhead for process creation and death and these processes are able to cache open files.

Conclusion

We believe that many interesting applications will be structured the way MacMix is. We have discussed some of the difficulties raised by such a structure. The rewards of overcoming them are hopefully demonstrated in the video tape of MacMix in action.

Acknowledgement

The UNIX host software for MacMix was implemented by Robert Gross.