Master Clock
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:
- 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.