Subject: Re: [linux-audio-dev] Introducing DMIDI
From: Phil Kerr (phil_AT_plus24.com)
Date: Mon Dec 17 2001 - 05:08:48 EET
Hi Martijn,
Comments inline:
martijn sipkema wrote:
> > There are a small number of issues to fix, but the basic concept of
> > having MIDI controllers broadcast data over a TCP/IP network and DMIDI
> > hardware clients translate this data into raw MIDI (in as close to
> > real-time as I can get) seems quite stable.
> >
> > The protocol is very simple, and does not seem to suffer from latency
> > problems, on my network anyway.
>
> 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.
>
> 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).
>
> 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.....
>
> 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?
>
> --martijn
This archive was generated by hypermail 2b28 : Mon Dec 17 2001 - 03:06:30 EET