Subject: Re: [linux-audio-dev] Introducing DMIDI
From: martijn sipkema (msipkema_AT_sipkema-digital.com)
Date: Mon Dec 17 2001 - 14:05:23 EET
> > 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
This archive was generated by hypermail 2b28 : Mon Dec 17 2001 - 13:56:07 EET