Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!mit-eddie!mit-amt!geek
From: geek@mit-amt.MEDIA.MIT.EDU (Chris Schmandt)
Newsgroups: comp.windows.x
Subject: audio servers
Message-ID: <1837@mit-amt.MEDIA.MIT.EDU>
Date: 12 Mar 90 22:13:36 GMT
References: <9003121606.AA03191@expo.lcs.mit.edu> <4840@crltrx.crl.dec.com>
Reply-To: geek@media-lab.media.mit.edu (Chris Schmandt)
Organization: MIT Media Lab, Cambridge MA
Lines: 39

In article <4840@crltrx.crl.dec.com> jg@max.crl.dec.com (Jim Gettys) writes:
>
>Before being so unpleasently nuked last month, Olivetti Research in Palo Alto
>was building a server called "VOX" which addressed these needs.
>
>I believe this is the correct course of action, until proven otherwise.  And
>there is no proof that audio is best done as part of the X server, at least
>yet.

As one of the people who worked on VOX (fortunately, at this point,
as a consultant rather than an employee) I must second Jim's point.
Personally I think even VEX may have gone too far, in terms of devices
"beyond the screen", but that's another matter.

VOX strongly resisted the temptation to put audio into the "window system",
although we felt there was LOTS to learn and borrow from with the X
model.  You don't want to clutter X with audio responsibilities; managing
audio is very different from managing more-or-less-static graphics.
Similarly, the audio equivalent of the window manager is likely to
be very different.

However, the original poster was commenting on the need for synchronization
across media.  This is the best argument for supporting multiple media
in a single server process.  With multiple processes, coordination may
become difficult, both because of operating system scheduling of the
processes, as well as a potential need for server-to-server communication
or double round trips to the synchronizing client.

On the other hand, I would argue that the operating system most of us
work on just won't support the fine grained sync necessary for, say,
coordinating stimuli for an experiment, so kludging things on top of the
X server is not the way to go.  For much of the synchronization that
application developers will require I suspect that processors are just
getting fast enough that cross-media skew due to scheduling is likely
to be minimal.  There are all sorts of other solutions, involving
scheduling events according to some external time base, using
either absolute or relative time.  But enough said for now.

chris