[e2e] Protocols for tightly synchronised multicast?
schooler at vlsi.cs.caltech.edu
Thu Aug 16 14:10:59 PDT 2001
Lloyd Wood asked:
>On Wed, 15 Aug 2001, Craig Partridge wrote:
>> In message <sb7953a8.099 at prv-mail20.provo.novell.com>, "Hilarie Orman" writes:
>> >My challenge problem for networks: nationally distributed musicians
>> >playing in concert.
>> We did that demo for DARPA successfully back in 1991.
>What was the music that was played?
We played the Haydn Piano Trio No.1 in G, the Finale movement.
There were several reasons for this choice.
The first was that we only had a couple musicians who were
willing to perform and who also happened to be working on the project.
As Steve Casner mentioned earlier, one of the trio parts was
pre-recorded (the piano part), and the other two parts were played by
live musicians, one in Boston (Martha Steenstrup who was at
BBN at the time) and one in CA (me, when I was at ISI in LA or
at the ACM MM'95 conference in SF).
The second reason we chose this piece was that we needed
a way for the different instruments to stay in synch with
each other. The piano part of this piece plays throughout,
and serves as a continuo. This meant it could behave as a
conductor or metronome. The piano part was therefore transmitted
and played out for the other instrumentalists, who in turn created
their accompaniment. All three streams of music were resynchronized
and played out at the listener sites, i.e., at DARPA or at the
ACM MM'95 conference.
A third reason for this particular piece was that the piano part
actually begins before the other two parts, so it provides an aural
cue for when to begin.
Note that the performers/conductor never got to hear the trio in
its entirety. Each performer only ever heard the piano/conductor
part of the trio. A somewhat contrived musical experience for the
The reality is that the speed of light in combination with transmission
delays place limits on how quickly music can be disseminated to
participants; participants might include individuals who are conductors
or performers or listeners or who want to be all of the above.
Listeners may not care how long individual streams need to
be buffered in ordered to be resynchronized, but the others do.
If you think about a trio, there is a fairly tight feedback loop
between musicians, in order to adjust tempo or volume or even to "tune"
to the appropriate pitch. The challenge with networked musical
performance is that there is perpetual lagtime. A performer only
hears events that are in the past. This is further complicated
with multiway performance, say with a distributed orchestra.
If the delays can be kept within normal for a co-located orchestra,
then some form of conventional performance is possible over the
network. Otherwise, I suggest we consider composing music that can
"survive" network delays. Meaning, write music that still sounds good
despite variable delays, still engages performers/conductors, and is
still pleasing to listen to even if each listener hears a different end
p.s. - For a high-level description of the demo, you might
browse the slides:
"Distributed Music: A Foray into Networked Performance",
International Network Music Festival,
Electronic Cafe, Santa Monica, CA (Sept 1993)
Eve M. Schooler Voice: 1-626-395-6498
Computer Science, 256-80 FAX: 1-626-792-4257
California Institute of Technology E-mail: schooler at cs.caltech.edu
Pasadena, CA, USA 91125 http://www.cs.caltech.edu/~schooler
More information about the end2end-interest