[sdiy] ADDA & MIDI over Ethernet/Firewire?

[Magnus Danielson]

From: Gene Stopp <gene at ixiacom.com>
Subject: RE: [sdiy] ADDA & MIDI over Ethernet/Firewire?
Date: Tue, 10 Jun 2003 14:32:15 -0700

Hi Gene,

> Me too! 100M Ethernet is pretty damn fast in an uncongested point-to-point
> local link. And soon will be the day that you won't be able to buy anything
> that doesn't go 100M/full duplex.

Indeed.

> Rid of 10M and collisions, this just may work.

Trouble is, in the 10 Mb/s shared-medium (really a community line) the
collisions where really straigh-forward. You either saw another packet going or
you saw your own packet crushed by some other signal.
In todays hubbed and switch world you actually have the same thing happening,
but within the boxes and they *really* doesn't solve any problem, just make the
problem a bit more hard to comprehend.

> Even through layer 2 store and forward switches, uncongested latencies can be
> as low as 14-15 microseconds with 64-byte frames. Throw in RTP encaps and you
> might get it to work over WAN links.

... given that you understood the untold system-architecture of RTP that is.
RTP only helps to pin some "time" onto you packet, but that's really all there
is to it (well, helps to bring the relative order of packets back since UDP
doesn't do it while TCP does). You need to reconstruct a running playback-time
which is sufficiently delayed to handle jitter while not adding too much delay.
This effectively calls for a software-based PLL.

To really make sense should both sender and receiver be under NTP control.
It takes some good planning to get good NTP-performance.

Toss in a parallel signal also under RTP and you have wondered into unchartered
space. You need to handle the RTP times individually and then make efforts to
bring them together for "lip-sync" as we used to referred to it back in the
days. Toss in different propagation delays for the play-out and you got
yourself a little problem to solve. Not unsolveable, just not "according to the
book".

RTP is simple and fairly straightforward. The common denominator you need.
The trouble is that you need to think hard just on the RTP implementation and
then figure out how things fit together in a larger system in order to get
things "right".

> <Gaaak choke sputter blap> uh, sorry, fell into the workspeak trap... for
> some reason I dread the idea of mixing work and hobby, for fear that I'll
> grow tired of my hobbies.
> 
> Oh Magnus, where are you? Surely you will chime in about this!!!

Sure thing Gene, sure thing... this is my home turf... ;O)

Anyone who still states that Ethernet or "IP" (we old farts say TCP/IP) is
"simple" haven't looked at the stacks of specs they make. They are also not
"simple" to fully comprehend and understand, and this is especially true when
it comes to the issues which they are really bad at telling.

Gene knows what it means sitting on the other side of the support-line than me.

Cheers,
Magnus - writing new standards for a living