Re: It had to be tried...
Re: It had to be tried...
- Subject: Re: It had to be tried...
- From: John Lazzaro <email@hidden>
- Date: Tue, 19 Nov 2002 11:43:45 -0800
Hi Bernd,
Thanks for the reply, a few quick points:
>
The IETF draft is talking about MIDI, DLS and SA content streaming over
>
UDP or TCP -
The scope is bigger. The goal is one packetization for three application
areas:
-1- content streaming over WANs
-2- interactive performance over WANs -- Network Music Performance (NMP)
as described in:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf
and as done by other groups throughout the world using different
approaches (such as the SoundWire group at CCRMA).
Note that a distinguishing feature of NMP is that players hear
the performances of remote players under the influence of the
network, but the network does not affect how they hear their
own performance. This makes the problem easier -- the real-world
latency comparison of interest is the acoustic delay musicians
experience when playing on the same room or stage, and the
techniques to compensate for very late packets and lost packets
only need to preserve the illusion of telepresence.
Commercial apps include multi-player versions of musical
games over home broadband connections.
-3- The most controversial application, replacing MIDI DIN networks
on stage and in the studio.
The IETF packetization has a feature set that can handle all three,
with enough configurability to switch off the unneeded features for
any one of them. For example, it has a "recovery journal" system that
keeps the MIDI stream integrity through packet loss, but this system
can be turned off for lossless links.
Most of your comments concerned -3-, a few thoughts:
>
Based on CSMA/CD's nature [...]
-A- Modern LANs use switched fabrics, and so collisions don't
happen on the wire. Switches are also getting more predictable
about queuing delay, driven by the VoIP market. And if designers
wanted to target the music market with switches whose temporal
performance was excellent, they could -- switch design is in
scope of anyone who knows how to write Verilog and program a
Xlinix chip, the undergrad logic lab here at Berkeley uses it
as the class project. To see what can be done latency-wise if
designers are determined, check out the stats on this router
(not a switch, a router!) from Cisco, customized for VoIP:
http://www.cisco.com/wwl/regaffairs/images/pdf/Dispelling_the_Packet_Loss_Myth.pdf
(Thanks to Phil Kerr for that link).
-B- Serious users, like studios, would put in a network for content,
buy high-quality switches, and keep non-real-time traffic
off that network. If QoS was available, it would be turned on.
Just like studios use +4 balanced instead of RCA jacks ...
-C- The biggest single market for -3- is a musician buying an
Edirol or MidiMan or Evolution controller with an Ethernet port,
and plugging into the unused Ethernet port on his Powerbook,
making a two-machine network. Loss and latency are not an issue
in this case. Advantages include (1) freeing up the USB port for
other peripherals (2) no USB driver maintainance issues (3)
better latency and jitter than USB.
>
Of course you could introduce timestamps, but this would further add
>
latency.
Excellent work out of GRAME, timestamps aren't an either/or for
interactive work, its a tradeoff:
http://www.grame.fr/~fober/RTESP-Wedel.pdf
>
And of course this would be a chance to reinvent some "musical
>
instrument digital interface" with a more generalized view -
This, actually, is a benefit to basing a MIDI standard on RTP. RTP
has associated session management tools (SIP for interactive work,
RTSP for streaming) that have a concept of negotiation of protocol
built in. So, two hosts could check to see if they both know "MIDI
2.0", and if so use it -- but if one doesn't, they could fall back on
MIDI 1.0. Just like modems negotiate ...
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.