[e2e] Protocols for tightly synchronised multicast?

Eve Schooler 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 
performers.

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

E.

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)
  http://www.cs.caltech.edu/~schooler/papers/NetMusicFest.ps


-=-=-=-=-=-

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 mailing list