[sdiy] MIDI over Ethernet

[Magnus Danielson]

From: Jim Patchell <patchell at cox.net>
Subject: Re: [sdiy] MIDI over Ethernet (was Microchip DSP kit $60 > AVR32)
Date: Tue, 25 Mar 2008 17:35:36 -0700
Message-ID: <47E99A58.2060607 at cox.net>

> Not quite as bad as all that.  UDP is deterministic on timing (on a LAN),

Yes and no. Depends on your timing requirements. If you run two Ethernet ports
back-to-back you have fairly good timing, until you add additional traffic as
it hits the play-out buffers. If you run through a switch, the other traffic
from other ports join in and helps to unstabilize the timing. Multiple hops of
Ethernet switches... it gets worse again. Even if there is no other traffic,
timing gets screwed up by a number of anisochronous and asynchronous mechanism
that contribute here and there on timing. May not be a sindfull load, but it
adds up.

> but is not guaranteed to get to where it is going (no handshaking).

UDP gives you the underlying datagram service, but without giving you the raw
IP access. It adds ports and a weak form of checksum. While the checksum is
weak, it is the only end-to-end checksum you have and if it is broken, the
packet drops as a result of bad checksum... and does not get delivered.

> TCP is always guaranteed to get to where it is going, but is a bit less
> deterministic as far as timing since there are a number of packets exchanged
> for each message.

TCP uses what is know as three-way-handshake to transport a "chunk" of data
and make sure it is received. It uses these in an pipelined fashion and uses
some fairly elaborate mechanisms to discover the depth of the pipeline and
making sure it adjusts to change in available capacity. Now, this goes both
upwards and downwards, so delay variations is signficant, as anyone loading any
larger chunk of data can experience on a daily basis.

> On a Local Area Network, UDP is more than adequate since the likely hood of a packet getting lost is quite infinitesimal.  On a WAN (the internet), UDP becomes problematic since packets can become lost and also arrive in a different order than they were sent out.

Indeed. Reordering is to be expected and dropping packets used to be the only
way to have sources to cool of on sending more packets. More recent TCP
features allow for better avoidance on dropping packets. This is a combination
of Random-Early-Discard and marking of supposidly discard packets as "I would
have dropped you". Sally Floyd did that work with Van Jacobssen.

> For a studio, Ethernet to me looks like a very nice way to go.  It is fun to work with.  The instruments can have their own "webpage" to configure them, or they can run a telnet server if you really want to keep it simple.

Oh dear... well... yes. As long as you don't get stupid and transmitt real-
time sounds over it (or at least not too much) then you are home free.
Loading the network down with traffic screws timing up first... but bursts can
lead to dataloss.

> Also, as was pointed out, with 1GB/s bandwidth, it looks pretty open ended to me.  As soon as I actually get a system up and running, I should be able to do some testing to see just how good or bad it might be.  I am planing to use TCP/IP to start out with...(it is easier). Commercial systems at present are using UDP...so lossy doesn't seem to be a problem.

I am not expecting GE to be dirt cheap just yeat. FE however is plentifull.

Eat a healthy diet of fibre and don't overload the Ethernet pipes too much to
stay out of trouble.

Webservers is nice and dandy, but they should be run as background processes
with no priority.

Cheers,
Magnus