MIDI Clock jitter related to (low) ASIO buffer size

[stuartm]

I had some trouble with MIDI Clock jitter from Live's master clock.
Last night I realised that (at least with my setup) the MIDI Clock jitter is related to the ASIO buffer size.
Maybe this is old news for some, but I couldn't find any similar postings about this.
And since a lot of people are complaining about Live's sloppy MIDI clock, I'll explain a bit.

The Setup:
Thinkpad W520, Win7 64bit, Live 9.1.2 32bit
-> Audio Out: via Saffire LE (Firewire) or Scarlett 6i6 (USB)
-> MIDI Out: to MIDIbox Sequencer V4 (connected via USB)
-> External Gear slaved to MBSeq: Machinedrum, Octatrack, Shruthi-1, Evolver etc.
Live is MIDI clock master, MBSeq is slave, forwards clock to external gear

The Problem:
I had this perfectly running tight and in sync (with adjusted MIDI Clock delay in Live of course)
Then had a few months of non-activity, changing stuff, moving etc.
Recently re-connected everything and: sloppy MIDI clock on the external gear.
At 135 BPM, the jitter was max. +/- 5 BPM, observed on the Elektron machines. But clearly audible in the sound of the slaved machines as skipping or sloppiness.

The Solution:
After a lot of head-scratching and changing things around without effect (older Live versions, things in/out of the MIDI chain etc.) I realised I had raised the ASIO buffer size at one point (for whatever reason). On the Scarlett 6i6 it was 15ms for example.
When gradually lowering the ASIO buffer size, the jitter of the received MIDI Clock got better and better.
Finally around 3ms ASIO buffer, no audible sloppiness in the slaved machines. On the Elektrons, I could observer max. +/- 0.2 BPM.
I could repeat this with the Firewire Audio Interface, which already gave a good result at 5ms ASIO buffer.
Same with the MBSeq out of the chain and Live directly clocking the external gear.

My Conclusion:
The larger the ASIO buffer size, the more jitter on the computer MIDI clock.
If I want a thight MIDI clock from the computer (i.e. Live), I have to use the smallest ASIO buffer possible.

Proposed Future Research:
- try to repeat with a different clock source on the computer
- get the ASIO buffer sizes in samples
- use a software tool (MIDI-Ox ?) to record the MIDI stream to numerically evaluate the clock jitter at different buffer sizes
- try to repeat on another machine

[Coupe70]

Strange. It would still have been bad, but kind of 'logical' if with lower buffer size
and therefor higher CPU load the MIDI timing would get worse. But the other way round..?
You should report your findings to Ableton support.

[stuartm]

I thought the same (higher buffer = more breathing space for the system), but apparently it's not.
Couldn't find anything on that on the net so far.

The low latency buffer also has an advantage for the other way round set-up:
with Live as MIDI slave and therefore latency compensation off, the small offset of delaying plug-ins is barely audible with that small ASIO buffer.

[stuartm]

Oh my, SoundOnSound indicated this already in an articles from 2002 (!)

http://www.soundonsound.com/sos/sep02/a ... an0902.asp

[...]

USB can add a small amount of latency -- and, more importantly, a larger element of jitter.

This is because unlike USB audio, which uses isosynchronous timing to guarantee its delivery time unless a disturbance is so large that it runs out of buffer space, USB MIDI uses asynchronous timing -- data is delivered as and when it gets through, and its arrival depends a lot more on other factors. Once you try to send both MIDI and audio data via USB, they have the potential for huge conflicts, and I would personally only recommend this approach when using a single product that takes care of both data streams. At least then its drivers will be carefully written to juggle the demands of both MIDI and audio, to ensure that both emerge with the minimum of conflict.

[...]

With this in mind I took some more measurements, first with a buffer size of 256 samples, giving a theoretical latency of 5.8ms (and with my Echo Mia a measured real-world latency of 8.0ms). This time the MIDI to audio latency varied from 10.3ms to 15.5ms, showing that the jitter component had risen to nearly 5ms, compared with 3ms for GSIF at the same latency. For those whose PCs can't for one reason or another manage this buffer size and have to work at 512 samples, although the reported latency inside Cubase is still just 11.6ms (real-world 13.7ms), the actual MIDI to audio variation measured from 16.0ms to 27.4ms -- a huge amount of jitter.

[eyeknow]

Omg, I hope I don't have to get a clock to run my soundcard...........

[Bdumaguina]

Thank you for this post, currently researching MIDI Clock issues on a similar system.

[nominalindltd]

I've been chasing this issue for several months and have tried all sorts of things and somehow kept stumbling over this as a possible solution. Sure enough, dropping the buffer from 4096 to 1024 or 512 helped immensely. I don't have a reading in ms but most recently I was just clocking the BPM on the incoming clock with Hydrasynth's arp and could watch it fluctuate by anywhere between +7.0 to 3.0 BPM more or less constantly. Since the Hydrasynth is also using that clock to sync it's on internal delay effect, it was EXTREMELY audible since you'd keep hearing the pitch on the delay correcting constantly. Things sound MUCH cleaner now and I'm only seeing the BPM fluctuate by 0.3 at a maximum. Thanks!