Subject: Re: [linux-audio-dev] Introducing DMIDI
From: martijn sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Dec 20 2001 - 13:40:28 EET
> > Therefore, a mecanism to compensate for the latency variation seems to
> > me to be necessary.
> >
> I don't think its always necessary -- MWPP should provide the freedom
> to implement latency variation compensation, but I don't think it
> should mandate it. In our experience playing over the CalREN 2
> Berkeley-Stanford and Berkeley-Caltech links, jitter compensation
> wasn't necessary; "play when received" worked well, as long as the
> "outliers" of very late packets were handled separately, using
> semantic rules (which is what the "ontime" and "late" flags codify).
I agree. The idea of combining messages into a packet might be interesting
when the source of the MIDI stream is a sequencer application instead
of a human playing on a MIDI keyboard. Here MIDI events can be known
ahead of time and could be sent in in bursts and the MIDI stream is often
less sparse when coming from a sequencer.
A (variable length?) delta time would enable the receiver to schedule the
events in the packet, but adding this to MWPP isn't trivial, at least the
MIDI payload would have to be parsed to know where a MIDI message
ends, it can't be just sent. This is not a problem I think.
It is also mentioned that combining MIDI events into one packet
reduces the chance of packet loss, but it does this at the cost of losing
more
MIDI events per lost packet, so I don't see this as an advantage.
> > Another point is the efficient use of the transmitted packets: sending
> > one packet for each event is probably not the best solution.
>
> Note that MWPP has a "MIDI Command Section" with a 6-bit length field,
> and that except for the first MIDI command, running status coding is
> permitted:
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |R|R| LEN | MIDI Command Payload ... |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Recovery Journal ... |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> So, schemes that code more than one MIDI command per packet are
> supportable under MWPP; sfront puts one command per packet in its MWPP
> implementation, but its not a normative part of the spec. What is lost
> in this simple approach is information about the temporal delay
> between commands -- as MWPP is written, the sender is claiming that
> all commands in the MIDI Command Payload happened at the moment of the
> RTP timestamp.
>
> One addition that could be made to MWPP, is a simple, efficient way to
> code this delta-t information, that doesn't impact the packetization
> for the "single-command-per-packet" case. However, the AVT culture is
> not to "add a feature because it might possibly be used" -- if the
> bandwidth reduction (relative to sending one-command-per-packet, each
> with its precise RTP timestamp) achievable by adding this complexity
> isn't seen as serious issue by the working group, the consensus might
> well be to leave the feature out.
MWPP as it is now has the possibility of combining several MIDI events
into a packet. MIDI events rarely occur at the same time exactly, unless
they are produced by a sequencer application. So for someone playing
a MIDI keyboard this funcionality doesn't make that much sense, or
I at least don't get it.
One last comment about the RTESP-Wedel.pdf. Millisecond timestamps
are used in it. I think this is too coarse, especially when trying to have
jitter
smaller than 1 millisecond, which should be possible on a LAN (with a
latency <<5 ms).
--martijn
This archive was generated by hypermail 2b28 : Thu Dec 20 2001 - 13:32:24 EET