Midi Merge Technique?

[Magnus Danielson]

From: Rene Schmitz <uzs159 at uni-bonn.de>
Subject: Re: Midi Merge Technique?
Date: Sat, 22 Jan 2000 22:17:02 +0100

> At 00:12 21.01.00 +1100, Paul Perry wrote:
> >looking on the scope at what comes out of the Korg KMS30 midi to din
> convertor,
> >I can only assume that the midi timing clocks have a pretty wide jitter on
> them 
> >as they come out of Cakewalk on my computer.
> >
> >Has anyone got gear to tell exactly how regular are midi clocks in the real
> >world?
> >
> >paul perry Melbourne Australia
> >
> 
> Hi Paul! 
> 
> You can also look at the data stream directly on a scope. I've once done it, 
> and found jitter. Also with Cakewalk. I don't know if other applications 
> are any better. 

Hmm... you guys are talking about MIDI and jitter... which makes me think...

There are a number of diffrent sources of jitter in such a system:

1) The actual clock. It jitters, it is in the nature of all clocks. The actual
   clock is divided down, but that just change the frequency and phase
   amplitude nature of the jitter. This is very small.

2) UART alignment jitter. This comes from the time the data becomes available
   to the next clock flank to start pumping the start bit. This is a little
   bigger. Also, this migth mechanism migth look diffrent between diffrent
   UARTs since you migth implement it diffrently. Most UARTs run at a higher
   clock (for the sake of the receiver syncronisation) so a transmitter may
   reduce the jitter by using some extra curcuit that does not change much
   else. I doubt that it is done, but it is possible.

3) BUS alignment jitter. This comes from the setup time and possible wait time
   if the bus is busy. Normally this is quite small, but the worstcase is not
   as limited as one would wish, so it migth peak about the UART jitter.

4) Scheduling jitter. Due to how well the scheduling of the OS/program
   cooperate migth some migthy terrible jitter occur. This can be many 10's
   of miliseconds without a blink.

5) Buffer jitter. Since you are merging two streams into a common output
   stream you run into classical buffer problems. If one merges two streams
   into one non-prioritized queue you get interstream dependencies on the
   timing side. The delay is due to the buffer fill level and the maximum
   transmission speed of the link.

So, what are you seeing? I doubt you are refering to 1-3. So, 4 or 5?

MIDI clocks are just specified as being relative in frequency and not much is
being said about jitter. Nobody really thinks about jitter since it is an
asynchronious protocol which by nature has varying delay. Jitter is the
property of some cyclicly reoccuring event, and this is exactly what an
asynchronious protocol isn't. If you try to send contious events over it you
may talk about jitter thougth. You could also possibly talk about jittered
delay as you send some message in and await it to pass through some system.
There is the cyclic event in your messurement and not in the system.

Anyway, I beleive nothing is being said explicitly, but the MIDI standard
carries many signs on optimations to reduce waiting time. For instance may
curtain messages be stuck into a long stream of another ongoing MIDI message,
this will certainly reduce the jitter. This is basically providing the
facitility for priority queues, a very usefull technique. This is also what
the 8:th bit is being spent on. Also, this forms the basis for a more complex
MIDI receiver which can be badly coded. One has to read the specs pretty
carefull to understand how to be able to do it properly.

I think we must realize that we have taken MIDI way past its original design
requirements and that eventually will something else have to emerge that
better suits the current needs and that can extend from where we are now and
not from where we where in the mid 80thies. Some small efforts have been
tried and all seem to have failed. I have some ideas of my own, which I love
to share, but I seen no way of having a commercial endorsment of them on the
large scale that is needed.

Cheers,
Magnus (who designs network protocols on dayligth hours)