Re: [linux-audio-dev] Introducing DMIDI

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Introducing DMIDI
From: Phil Kerr (phil_AT_plus24.com)
Date: Tue Dec 18 2001 - 03:40:23 EET


Hi Martijn,

The max. packet size at the moment is 256 bytes. This is because I'm unable to
read the UDP packet size directly and strlen would barf at the first 0x00
value, so I use the fourth node id byte as packet size. This is top of the
list to fix!

The theoretical max for UDP packet size is a shade under 64k, but few platforms
support this limit, some support 32k some only 8k. So the most portable size
is just under 8k, although your system may handle more.

DMIDI is only a packetizing protocol, data is wrapped-up with a node id , then
sent. On the receiving end the raw midi data is sent to the device serially.
As you mention, allowing the hardware to detect bad data is far preferable than
trying to emulate this in software. So you can have a DMIDI packet containing
note-on on chan 1, pan on chan 2 and so on. DMIDI routes this out to the midi
device as raw MIDI data, then all the normal functionality, quirks and
failures of MIDI take over. To MIDI this data appears on the wire as if it's
come from any other MIDI device.

This also affects interleaving and the whole way that nodes interrelate. If
you have two MIDI sequencers sending data to one sampler, you may or may not
encounter problems. Same thing with DMIDI, if you can do this with adverse
effects using stock MIDI kit then you'll have the same problems.

Node id's are really an extension of midi chan's. You can call it a cable
number as well if you wish :) if you have 5 nodes each with a MIDI device on
chan 10 how do you say 'kick drum1 on the second Korg on the right, not the
Roland on the bottom' . I used sysex manufacturers ID as the basis for node
ID's as this seemed a reasonable thing to do. The initial spec, specifies that
the values in the node ID section should be hex, but they could be
alphanumeric, so instead of node 0x1122ffee the node could be 909a or krg1.
Suggestions welcome on the best approach. DMIDI then broadcasts the packed
over the subnet and clients should then examine the packet, check to see if the
node ID is theirs (or the first byte starts with 0xff) and then pass the
remaining data to the MIDI hardware, or not as the case may be. The DMIDI
hardware client can receive interleaved data without problem, but the existing
MIDI problems will still be present. Data to chan 1 on node 0x11223344
shouldn't affect data to chan 2 on the same node.

Interleaving sysex data with normal data isn't good. DMIDI doesn't impose any
restrictions on this problem over MIDI. If you are in the middle of sending
sysex from whatever device (say chan 1) and you send note info to chan 1, you
will get problems. However if the sysex is contained within one DMIDI packet
it's going to be dispatched to the device in fairly rapid order and this will
minimize the problem (but not solve it). But DMIDI shouldn't cause problems if
half way through receiving sysex on chan one it switches to sending data to
chan 2 then back. Technically the MIDI device doesn't know anything about
who/what has supplied the data and shouldn't care if it's switched for a moment
(I presume internally the hardware buffers the sysex until it receives an EOX
or a value greater than 0x7f).

On a private network, not a network sending buckets of NFS/Samba/ARP/HTTP
packets, and with half decent NIC's and cable you should have latencies less
than 1ms. In work I don't cut-back on hub's, switches or cable I buy the
best. I've seen and heard too many horror stories concering large scale
systems being held together with $20 hubs and taped together patch cables.
Would you cable your studio with bell-wire, thought not! If you are going to
use a network for anything resembling real-time, or high-volume, applications
you do not buy cheap.

I initially looked at RTP for exactly the reasons you mention, but I prototyped
things using plain UDP just to see what worked out. So far RTP looks like
overkill when you look at the cost/benefit ratio. I've only managed to lose
packets when pushing things hard. But from what I understand of RTP the same
thing would/could happen if the protocols are switched. The timestamps are
used for stream reassembly or deciding if the datagrams are too late and should
be dropped. There is a point where you cannot compensate for lousy networks.
However, if RTP is the way to go to provide an extra level of 'protection'
against delays then this is the way it goes. This is no. 2 on the list :)

DMIDI packet saturation will have the same effect as saturating a MIDI device,
packets will be dropped silently, but i've been able to do this with my Atari
ST/Cubase and a number of Pro. MIDI devices for ages :)

Phil

martijn sipkema wrote:

> > > why did you choose to have an udp packet per midi message and not
> > > have one midi byte per packet?
> >
> > Both are allowed. The example dmidid client receives bundled MIDI data,
> but
> > transmits single packets per midi byte.
>
> OK. Should there be a maximum size for a message? it is
> 256 right now, but you intent to remove that?
>
> Sending one byte per UDP packet has the advantage that
> if one packets is losst, e.g. a byte from a note on message,
> the receiver will be able to at least know that an error occured.
>
> How is interleaving handled. Is the transmitters IP used to seperate
> different streams? Can one host send multiple streams to one 'node'
> on another host?
>
> Why did you choose for the node number in its current form? Why
> not just a 'cable' number?
>
> > > how will sysex be handled?
> >
> > Either as one DMIDI packet, or as a stream of single packets. To the
> > receiving MIDI device there shouldn't be any difference. I'll check
> tomorrow
> > if this is a problem (so far only tested with note and control data).
>
> Again the issue of interleaving. sysex may only be interleaved by MIDI
> realtime
> status bytes. Any other status will cancel/stop the sysex transmission.
>
> > > there is nothing in the protocol to handle losing packets or to prevent
> it.
> > >
> > > a constant delay for the midi stream is often acceptable and the
> protocol
> > > might use this for handling loss of packets. perhaps RTP could be used?
> > > sending a packet a couple of times can reduce packet loss.
> > >
> > I'm looking at either TCP or RTP as replacement protocols if loss becomes
> an
> > issue. I'd only recommend DMIDI on a private network, not a busy public
> one.
> > Right now consider your network as a musician, bad network.....
>
> TCP might not be the best solution, but using RTP should be investigated
> IMHO.
> I'm not sure, but doesn't RTP have timestamps? The current DMIDI protocol
> doesn't have timestamps and as such doesn't allow for sending packets
> slightly
> ahead to reduce jitter and have a acceptable (constant) delay, e.g. 2ms
> (less or
> more depending on the network).
>
> > > the protocol probably should also have a requirement to the data rate,
> > > i.e. it should not allow a higher data rate than MIDI 1.0
> >
> > Good point. I saw it as a good sign when I saw RX buffer errors on my
> > Promix, it meant I was sending data *fast* enough! I've not seen anything
> > else filter for this, do you regard this as a big problem?
> >
>
> I'm not sure, is there a way for the receiver to indicate it is not able to
> handle
> the incoming flow if UDP packets (flow control) or will they just get losst
> eventually?
>
> --martijn


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 18 2001 - 01:37:17 EET