Master Clock

Registered by RJ Skerry-Ryan

For syncing to a master clock, there needs to be a master clock.

Blueprint information

Status:
Complete
Approver:
RJ Skerry-Ryan
Priority:
Medium
Drafter:
RJ Skerry-Ryan
Direction:
Needs approval
Assignee:
Owen Williams
Definition:
New
Series goal:
Accepted for 2.0
Implementation:
Implemented
Milestone target:
milestone icon 2.0.0
Started by
RJ Skerry-Ryan
Completed by
RJ Skerry-Ryan

Related branches

Sprints

Whiteboard

(sean) How accurate do we want this clock to be? FWIW, a MIDI beat clock (24 pulses per beat) requires microsecond precision to keep drift within reason. What timing source can we use on each platform that's this accurate?

(owen) My understanding is that midi is full of jitter, and perfection is rarely achieved. As long as the average over one or two beats is correct, I think that's enough.

(sean) Okay, but I'm talking about Mixxx's master clock here that you've implemented. How accurate is it so far? How much jitter does it have now?

(rj) the engine callbacks are very very precise (i.e. their view of time is dictated by a real-world crystal pulse) but we only get 1000/latency callbacks per second.

I don't know where you're getting microsecond requirements. A 160BPM song has 2.6 beats per second. If we need to send 24 pulses per beat then that's 64 pulses per second. That means sending a pulse every 15.625ms so the max required latency to accomplish that for a 160BPM song is 15.625 ms.

Because the callback periods won't always line up with the MIDI clock pulses, there will be inaccuracies unless the callback periods are twice the MIDI clock pulse periods (by the nyquist sampling theorem). So if you want a jitter free output pulse train (with respect to the engine ... this whole analysis completely ignores the huge variability added by the signal travelling from Mixxx engine -> CO system -> Qt event loop -> Controller event loop -> PortMIDI -> OS MIDI layer.) then for a 160BPM song your latency needs to be 7.8125 ms.

As Owen mentions -- if MIDI clocks are full of jitter usually and if people low-pass-filter the incoming midi-clock then it should be fine as long as we do something resembling the right number of pulses per second. QTimer is a non-starter for this since it is truly unreliable. The other time based option is using porttime.

I believe PortMIDI supports scheduling messages by providing timestamps. We could queue up a bunch of messages (i.e. as many as we want to send between engine callbacks) and let the OS dispatch them at the correct intervals, right?

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.