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. |