Midi clock behind time

[rutsch]

Hi there,

I'm using Mixbus on Linux and I have problems to get a tight/usable Midi clock. The generated MIDI clock is a lot behind the time of Mixbus. I tried various Jack/Alsa settings (Jack Midi, Alsa RAW devices, etc) without success. Other programs like Renoise or Bitwig are generating a really tight clock signal, they use Alsa Midi devices as I know.

Any tips to create a tighter clock signal with Mixbus?
Is there some kind of latency setting for the clock signal?

Thanks in advance!

[allank]

ALSA sequencer set to use HPET device for timing.
Definitely use an RT-kernel .. I found this critical for tight MIDI timing.. (not as necessary for audio, don't ask me why, but that's what I found)

---

YMMV.. I also use external clock and still found weird timing issues until I used an RT kernel.. (also using a low period setting of 64 or 128)

[rutsch]

I'm already using a PREEMPT kernel and a system-timer frequency of 1000 Hz in my kernel configuration. Will try a RT and HPET. Thanks!

[rutsch]

Ok, compiled a realtime kernel for my Debian 8 machine. HPET is also enabled in the kernel configuration. The Midi clock is more in time now when using a buffer of 64 or 128. Still not as good as the clock of Bitwig Studio or Renoise but usable. Thanks again for the hint.

@allank
What distro do you use? Are you using Alsa Midi devices or Jack Midi with a2jmidi?

[Patrick Kox]

Ok, compiled a realtime kernel for my Debian 8 machine. HPET is also enabled in the kernel configuration. The Midi clock is more in time now when using a buffer of 64 or 128. Still not as good as the clock of Bitwig Studio or Renoise but usable. Thanks again for the hint.

@allank
What distro do you use? Are you using Alsa Midi devices or Jack Midi with a2jmidi?

you can try the Realtime Quick Scan to check if your system has all the correct settings.

it's a perl script.

On my system with custom kernel I get 2 "not good" messages.
One is about tempFS (or something like that) and the other is about preempt kernel not set.

the first error can be ignored (outdated as I'm told) and I don't understand the preempt error since I'm certain it's set in my kernel .config when compiling.

On the other hand some people say that this quick scan is not fully accurate but I'm happy with it (I don't use MIDI so cannot comment on that).

Oh, it's been a while since I've compiled my last kernel, but I think Realtime and Preempt (full preempt) settings are 2 different things so I think you'll need to set both (I can be horribly wrong though)

[rutsch]

Thanks, Patrick. Will check the script.

[x42]

Sorry, late to the party. For Midi Clock and Midi Timecode generators, Mixbus does not yet take any port latency into account. The generated Timecode is at least one cycle behind.

Best you can do at this point in time (Mixbus 3.3) is to run with smaller buffer-sizes.

---

EDIT: I was wrong above. That would explain if the generated timecode was too early (not too late). This is because (1) the timecode needs to be sent early to for the midi-port-latency itself, but (2) delayed by the worst-case latency to audio, so that things align.
Anyway for MTC this is fixed now, midi-clock (position) not yet.

[rutsch]

Thanks for the info!