Midi Merge Technique? (Jitter)

[Magnus Danielson]

From: "Batz Goodfortune" <batzman at all-electric.com>
Subject: Re: Midi Merge Technique? (Jitter)
Date: Sun, 23 Jan 2000 14:22:25 +1000

> Y-ellow Y'all.
> 	it just occurred
> At 02:43 AM 01/23/00 +0100, Magnus Danielson wrote:
> 
> [bobbit]
> 
> >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.
> 
> There is one thing that all of us have overlooked as far as jitter is
> concerned. Including myself until now. And that is, the receiving end, if
> it's any good, has to have a PLL or fly-wheel circuit. Whether that be
> software or hardware. And what this does is overcome Jitter.
> 
> Often called a flywheel circuit because of it's similarities to a big heavy
> flywheel with a lot of momentum. It takes a lot to change the speed over a
> long time. Which means the speed is pretty damn constant at the receiving
> end. regardless of how much jitter there is. (to a point of course)
> 
> And of course. The reaction time of the PLL is set up so that a fast rate
> of change (accellarando/decellarando) can occur but jitter and even missing
> pulses can be circumvented.

Are we talking about the UART?

Since asynchronious is as it is will no normal synchronisation occur, but you
oversample the input by about 16 times and sample with the local baudrate
generator and uses the start bit to synchronize for the following bits, which
is enougth to survive until the stop bit, then for the next byte you
synchronize again. It is stupid in a way, but it works and millions and
millions of users depend on it dayly for their Internet access.

You can't use PLL/flywheel solutions on asynchronious communication just
because you never know when the next message is comming, if ever. The solution
is simple and robust but take some overhead (start and stop bits).

But then, UARTs isn't the main source of jitter.

If we are not talking about the UART, then we come up to the MIDI message
stream and how the accumulated jitter is being treated in software (which is
most probable). Here you should have a PLL with a flat jitter transfer
property and a low frequency cut-off so that the damping gets enougth without
putting too hard requirements on the input buffer and becomming too sensitive
to unstability in the local clock. I guess you could make huge misstakes in
this PLL, since most people doing this stuff is not used to think about jitter
and PLL properties in synchronious systems.

One of the things which limits the system is the tempo changes, since this
put the requirements for quick changes and this forces the PLL responce time
down and thus the filter cut-off up. This means lower jitter attenuation.
Most PLLs are 2-poles and occasionally you see 3-poles. There are reasons for
that.

> So I guess, as long as the jitter isn't so bad that it represents an actual
> tempo change, there isn't going to be much of a problem.

Well, as long as you don't preceive it as a note comming too late or that the
colour of a cord or something get's changed (due to the differing times) I
think you should be pretty well off, but MIDI is a messy thing. You really
want to keep timing sensitive MIDI stuff on it's own buss away from large bulk
messages.

Cheers,
Magnus