[sdiy] ADDA & MIDI over Ethernet/Firewire?

[Magnus Danielson]

From: ASSI <Stromeko at compuserve.de>
Subject: Re: [sdiy] ADDA & MIDI over Ethernet/Firewire?
Date: Wed, 11 Jun 2003 20:34:07 +0200

> On Tuesday 10 June 2003 23:22, Neil Johnson wrote:
> > > I just find that MIDI over Ethernet is set to become an IEEE
> > > standard.
> >
> > Oh great, YAS syndrome strikes again (Yet Another Standard).

Standards are great! Everyone should have one! ;O)

The good thing with standards is that people (when doing it _properly_) make
available solutions for everyone to agree on and use as a common interface for
interchaning signals. Both vendors and users gain from such a common ground,
especially when there is not too much of boogy-traps (too much IPR and
obnoxious layers/"buissnessmen" involved, which is a real no-no).

The bad thing is when there is too many standards or if they are poorly
written. Then there is no real gain. You want enougth to be flexible, you want
sufficiently few so that you don't have to have a cascader of converters just
to do regular "buissness".

> I agree, I was a bit disgusted as well. On the other hand, there are 
> Linux drivers and I don't use the computer for anything but bank 
> backups and OS updates - that should work and if it gets widespread 
> enough to be able to control a MIDI router from Ethernet, this would 
> suffice for me.

Such a standard should be simple enought to do.

> > As John says, it'll be interesting to see how they graft the desired
> > QOS on top of TCP/IP.
> 
> IMHO this would only work (with some limited success) if all ports on 
> the network were throttled for "normal" traffic. But I really would not 
> trust this "solution" enough to not dedicate the wire anyway.

Agree. Realtime traffic in the network means other trafic has to step back,
which is hard for some to understand. Either all the terminals obey, or the
network elements they connect to make them to.

> If you've followed the earlier discussion I already have come to the 
> conclusion that I'd just use the physical interface to FastEthernet 
> anyway and put a dedicated protocol on top of that that can deal 
> properly with the realtime nature of the data.

If you only use Fast Ethernet as a new MIDI physical interface but on speed,
then not much have to be done really. If you want other traffic to blend in,
then you start to be in trouble.

What a Ethernet based MIDI could do better than the original MIDI is to allow
8 bit octets and the much compacter and easier way to package data you could
acheive. The framing is already done by Ethernet and "running MIDI" could be
done by separate packets. Would allow for a cleaner interface. However, now we
are modifying another layer of the MIDI spec, but this is not necessarilly bad.

> I'm still somewhat undecided on wether it's necessary to integrate 
> Error Correction - the allowable BER from the spec is a bit on the high 
> side for audio, however I'd expect the typical network to exhibit much 
> lower rates. I've checked the error counters of the GbE->FE switches 
> back at the university regularly and I haven't had a single instance of 
> packet errors that didn't originate in a physical fault of either 
> interface or cabling. This was pretty amazing, given that the diameter 
> of the network was almost the allowable maximum and a tram line just a 
> few meters outside produced heavy EMI (the CRT all had to be replaced 
> with LCD eventually). So error detection and location of the faulty 
> segment might be all that is necessary.

The maximum size actually has nothing to do with BER. The BER you acheive from
actually transfered packets isn't bad. It's when packet loss due to buffer
overflow occurs that you get gray hairs (no, instant white!).

Gigabit Ethernet is good for at least BERs of 10^-12 if you don't abbuse it
too much. I haven't checked Fast Ethernet, but similar numbers isn't
unreasnoble. For the sake of MIDI it is more than enought.

Cheers,
Magnus