View Issue Details

IDCategoryLast Update
0008153bugs2020-09-01 10:08
ReporterDirk OffringaAssigned Tox42 
Reproducibilityalways 
Status assignedResolutionopen 
PlatformWindows 10OSWindowsOS Version10
Product VersionMixbus 6.x 
Fixed in Version 
Summary0008153: Midi Real Time messages are sent too early (Mixbus AND Ardour)
Description
I’m using Mixbus 32c V6.à.655 on Win10, 48k, 1024 buffersize, ASIO. I have an issue with the midiclock and/or the start/continue messages. They start/continue messages are always sent too early in relation to the grid, and this offset seems to be related to some latency compensation: if I insert a plugin that needs PDC (even the limiter on the main bus) the start/continue messages are issued even earlier but I did not identify a clear sample-accurate pattern. I spent countless hours checking every possibility I could think of, and reported the issue to Harrison support. as well. On the other hand, audio latency compensation is spot on: I have correctly calibrated the audio hardware and it’s sample accurate.

When using the midi device calibration results, the offset is worse than when leaving them at default 0.

The Real Time start/continue/stop messages should be sent when the actual audio starts to sound, so that synced external sequencers are synced to the recorded audio. This means that all latency compensation should apply to these RT messages too. This seems not to be the case. When a external sequencer receives a start message, and we record its (audio) metronome, the record metronome shoul be perfectly aligned on the grid.

I downloaded Ardour to doublecheck and it has the same behaviour.

Please note this is MidiClock, not MTC.

Steps To ReproduceMake sure audio and midi have been calibrated. Patch midiclock to the midiport a sequencer is connected to. Patch the sequencer's audio click output into a audio interface input, and connect to a Ardour track. Start Ardour and record that click. Check if the click is aligned on the grid.

Even when routing internally, there's an issue:

Patch Ardour click to an audio track input, record metronome. Check if the click is aligned on the grid.
TagsNo tags attached.

Relationships

related to 0008154 new Midi clock should stream always 

Activities

x42

2020-05-31 22:47

administrator   ~0024331

This should be fixed since Ardour 6.0-44-gef94663d1c

The main problem was that Ardour just sent start/continue message instantly, and not at MIDI Clock downbeats. Nor was the clock every in sync with music-time beats.
In all versions prior to 6.0.44 Ardour just used it to indicate [clock] speed (and state).

Dirk Offringa

2020-08-26 12:04

reporter   ~0024961

Hi, following up on a thread on the forum: I downloaded the latest version and noticed the change. BUT: now externally synced gear is ONE buffer late. It's an improvement over the earlier situation, where it was always early and randomly so. The current issue is reproductible, not random: one buffer. I experience SOME extra offset, but didn't identify it yet and it might be due to my own hardware.

Dirk Offringa

2020-08-26 14:04

reporter   ~0024962

I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages, IMHO it should be!

x42

2020-08-26 15:54

administrator   ~0024963

Thanks for the feedback! So we're making progress at least.

> I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages.

Odd, It has an effect here. Both Audio and MIDi calibration are in use and port latencies are set correctly.

Ardour's clock is aligned to the master-bus's output (incl. playback latency). The clock (and playhead position) matches "what you hear at the speakers".
The MIDI signal is likewise aligned, and sent early by difference of Audio - MIDI port playback latency.

However we can only measure **round-trip** latency (MIDI out -> MIDI in, Audio out -> Audio in), the absolute alignment of MIDI-out -> Audio in is unknown.



> BUT: now externally synced gear is ONE buffer late.

That is interesting. Could you describe your test setup? It'd be great if I could reproduce it somehow.
Are you perhaps directly feeding Ardour's MIDI clock output back into an Ardour Audio port? That could explain the 1 cycle offset.
 
Can you test this independently?
Play back this Ardour session. Record the audio of the slaved synth and Ardour's master-bus audio output with a different device (or an independent Ardour session) and see if the audio aligns.
I'd also start at a time other than 00:00:00:00 first.

This tests alignment of Audio out vs MIDI out. It'd be interesting if this is exactly half of the buffer-size.. or if it aligns.

Dirk Offringa

2020-08-26 18:42

reporter   ~0024964

I just spent over an hour typing in a detailed report bu my session expired and all was lost.

Dirk Offringa

2020-08-28 09:26

reporter   ~0024970

I take some time to redo my lost report (I've a very tight schedule ATM)

In the screenshot below, you see two lanes.

These are recordings of the (stereo) output of a Elektron Analog Keys, that has a Minibrute2S connected to it's external input, so the both synths are mixed to the same output, and thus using the same input on the mixer, and sent over the same direct-out USB channel, so record on the same track.
Audio path: AK+MB2S => Soundcraft mixer with USB/MADI card=> USB out => Ardour. Buffer size set to 1024.

The downward square pulse is the AK click, the other, longer "squirp" sound is the MB2S metronome "click".

LANE ON TOP: both synths are clocked by Ardours midi clock (via a iConnectivity iCM4+ interface/router). The orange line on the left is the playback head position on the beat. Both clocks are 1 buffer late.

LANE ON BOTTOM: AK remains clocked by Ardour midi clock. The MB2S is clocked over it's analog clock input. To do so I use the ERM VST plugin (usually used by their MultiClock) that outputs audio pulses as soon as the sequencer is running (it reads a looping audio file, AFAIK). The audio from that track is patched to a output of the Souncraft desk and then into the MB2S clock input.
This clock is right on the beat as expected, and the AK click didn't move (as expected too)

This illustrates the issue perfectly.

Ardour sync test.JPG (68,679 bytes)
Ardour sync test.JPG (68,679 bytes)

Dirk Offringa

2020-08-28 09:30

reporter   ~0024971

"Can you test this independently?
Play back this Ardour session. Record the audio of the slaved synth and Ardour's master-bus audio output with a different device (or an independent Ardour session) and see if the audio aligns.
I'd also start at a time other than 00:00:00:00 first.

This tests alignment of Audio out vs MIDI out. It'd be interesting if this is exactly half of the buffer-size.. or if it aligns. "


I recorded the main output of my mixer, with the recorded click playing, and the synced live-click. They (almost) align. (Give or take some jitter). On top: the recorded click, bottom: recorded+live

Ardour Align clicks.JPG (38,015 bytes)
Ardour Align clicks.JPG (38,015 bytes)

x42

2020-08-28 16:46

administrator   ~0024972

Thanks this is good information!

So in summary:

1. When playing, MIDI-clock and audio playback are aligned. (give of take expected MIDI jitter of ~1ms)
2. Absolute alignment with time grid is off by 1 process cycle (buffer-size samples).

I still do not know if the offset happens when recording or during playback.

When you did the AK and MB2S test, have you recorded the result with a separate Ardour instance, or the same Ardour instance that also produced the MIDI clock?
If the latter, you will have to change the track's input to use "Alignment: Align with capture time" (track header context menu), since Ardour cannot deduce the connection.

PS. VST2.x bar/beat timestamps are not latency compensated in Ardour 6, so they will be early by the playback latency, usually 1 cycle early, minus a few samples.
This is usually not an issue for VST2 synths producing audio, but VST MIDI outputs will be offset. (So far only LV2 and AU are correctly aligned to music-time), and in your case you're just lucky that this cancels out.

Dirk Offringa

2020-08-28 19:10

reporter   ~0024973

"When you did the AK and MB2S test, have you recorded the result with a separate Ardour instance, or the same Ardour instance that also produced the MIDI clock?"
The same instance, Ardour crashes when attempting to launch a second instance, probably a Windows issue , related to the ASIO driver

"VST2.x bar/beat timestamps are not latency compensated in Ardour 6, so they will be early by the playback latency, usually 1 cycle early, minus a few samples."
I don't use any Virtual instruments, just reverbs and delays. I use midi only for the clock sync (but I might need to go for a ERM multiclock if we can't sort this out in a reasonable time window ;-) )

"I still do not know if the offset happens when recording or during playback."

During recording for sure, otherwise it wouldn't show on my screenshots. On playback without recording, I'll try to do the test using another recorder when I manage to free up some time to repatch stuff

Dirk Offringa

2020-08-28 19:17

reporter   ~0024974

"If the latter, you will have to change the track's input to use "Alignment: Align with capture time" (track header context menu), since Ardour cannot deduce the connection."

If I set alignment to "capture time" the offset becomes ridicoulouly high, if I leave it on "auto" it looks good

TOP LANE: aligned to "capture time"
BOTTOM LANE: aligned auto ("existing material" whatever that means)

Both are AK (DIN MIDI) +MB2S (ANALOG MIDI)

I recorded the main output of my desk with a synth live + it's recording but the result is the same as what I reported above: I don't see how this can be any different. Maybe I do not understand what you want me to do here

alignment options.JPG (48,075 bytes)
alignment options.JPG (48,075 bytes)

Dirk Offringa

2020-08-28 19:20

reporter   ~0024975

I said "I recorded the main output of my desk with a synth live + it's recording but the result is the same as what I reported above: I don't see how this can be any different. Maybe I do not understand what you want me to do here" but I actually do understand: it doesn't matter if Ardour is recording or only playing back: both the recording and and the live sound remain aligned in both cases.

x42

2020-08-28 19:21

administrator   ~0024976

Ah yeah, Windows/ASIO mandates exclusive access. So a second soundcard would be needed.

Regarding VST2.x offset, I meant "ERM multiclock" in Ardour.
When doing playback alignment tests, you could also check the output of Ardour's metronome along with alignment audio/midi playback.

If all playback is in sync (give or take some small MIDI jitter), then I'm happy. -- The only clue I currently have is that capture alignment is not correctly set.
I'll investigate, but I cannot provide any ETA when this can be sorted out. I'll likely have to acquire and dust off some equipment to check for myself.

Dirk Offringa

2020-08-28 19:30

reporter   ~0024977

Ok, let me know If I can some more. I appreciate your implication, thanks for this!

x42

2020-08-28 19:31

administrator   ~0024978

" it doesn't matter if Ardour is recording or only playing back"

No, I was thinking of the simple most setup using external validation. When you're on stage what matters is what comes out of the speakers. So I was suggesting to test if everything lines up there.

When you play some Audio track, and record it back onto a different track in Ardour it should align. That is usually guaranteed by measuring can calibrating latency.
So I'm surprised that there can be an offset since above you've shown in Ardour Align clicks.JPG that playback is aligned.

Something doesn't add up.

Dirk Offringa

2020-08-28 20:10

reporter   ~0024979

Here's Ardour's own metronome plus a synth's metronome synced to Ardour over DIN MIDI (the square pulse). The Ardour metronome is spot on.

Dirk Offringa

2020-08-28 20:46

reporter   ~0024981

Oh, and BTW:
"> I want to add that the I/O latency calibration for the midi ports has no effect whatsoever on the RT messages.

Odd, It has an effect here. Both Audio and MIDi calibration are in use and port latencies are set correctly."

I double/triple checked with both normal and totally insane values and can confirm that Start/Stop messages are not affected at all by these settings. If they were, my current issue would be a no-brainer: I would have set an output latency value and that's it, and I could even do thi on a per-port basis to align synths with slightly different response times!

Dirk Offringa

2020-08-29 22:51

reporter   ~0024982

Hi Robin, I figured out a way to accurately sync my external gear to Mixbus/Ardour. By "accurate" I mean really accurate: I have 6 sequencers/drum machines running at once, I record each on different tracks and when playing back the recording WHILE leatting the sequencers run alongside in sync there's no phasing and everything is on the grid so I can punch in/out without cutting off the head of a kick . That's what I need. But I used Elektron's Overbridge to do this, via a Digitone synth which puts out the midi clock. By adjusting it's extensive buffer management I managed to precisely glue the beats to the grid (within the limits of each device, they all have some inherent latency of a couple of samples).

 So for now I can get to work again without needing to manually align each take. I guess Overbridge sync is sample-based like the ERM solution, but it talks directly to the Elektron hardware over USB so it bypasses the audio interface altogether. Of course if you need more information I'm OK to do more testing and help a bit if I can. Ardour/mixbus is already pretty good at aligning stuff (I compared briefly to others DAW's I have and they are far worse as far as midi sync goes!), it's actually near-perfect, if you guys could only fix this issue it would be amongst the best out there. (And get the midi-latency compensation to work would be nice too.... )

Cheers, and thanks for the great job you all do here!

x42

2020-08-30 23:24

administrator   ~0024990

The capture alignment was fixed in 6.2-227-gb326b8e462 (now systemic MIDI latency is correctly offset), and the bug also explain perfectly why the offset was always a multiple of the buffer-size.
In my prior tests I was just lucky that it was zero * buffer-size.

Dirk Offringa

2020-08-31 06:23

reporter   ~0024992

Hey that's good news! So my findings were correct.... that's reassuring. Thanks!

Dirk Offringa

2020-09-01 09:19

reporter   ~0024997

Hi Robin, where can I download that build? I downloaded the official release but it is stil 6.2.0 and do you know when there will be a official MixBus build with this fix? (or do I need to talk to Ben at Harrison about it?)

Thanks!

x42

2020-09-01 10:08

administrator   ~0024998

https://nightly.ardour.org/ -- It will be in upcoming Ardour 6.3.0 when that's released. That will be soon, since for Ardour we roughly aim for 2 months between minor versions.

There are also updated Mixbus nightly builds with this fix, but you do have to ask Ben for for a beta-version (Mixbus 6.1.229 or later).

Issue History

Date Modified Username Field Change
2020-05-27 11:29 Dirk Offringa New Issue
2020-05-31 22:47 x42 Assigned To => x42
2020-05-31 22:47 x42 Status new => feedback
2020-05-31 22:47 x42 Note Added: 0024331
2020-06-01 17:38 x42 Relationship added related to 0008154
2020-08-26 12:04 Dirk Offringa File Added: ardour midiclock latency.JPG
2020-08-26 12:04 Dirk Offringa Note Added: 0024961
2020-08-26 12:04 Dirk Offringa Status feedback => assigned
2020-08-26 14:04 Dirk Offringa Note Added: 0024962
2020-08-26 15:54 x42 Status assigned => feedback
2020-08-26 15:54 x42 Note Added: 0024963
2020-08-26 18:42 Dirk Offringa Note Added: 0024964
2020-08-26 18:42 Dirk Offringa Status feedback => assigned
2020-08-28 09:26 Dirk Offringa File Added: Ardour sync test.JPG
2020-08-28 09:26 Dirk Offringa Note Added: 0024970
2020-08-28 09:30 Dirk Offringa File Added: Ardour Align clicks.JPG
2020-08-28 09:30 Dirk Offringa Note Added: 0024971
2020-08-28 16:46 x42 Note Added: 0024972
2020-08-28 19:10 Dirk Offringa Note Added: 0024973
2020-08-28 19:17 Dirk Offringa File Added: alignment options.JPG
2020-08-28 19:17 Dirk Offringa Note Added: 0024974
2020-08-28 19:20 Dirk Offringa Note Added: 0024975
2020-08-28 19:21 x42 Note Added: 0024976
2020-08-28 19:30 Dirk Offringa Note Added: 0024977
2020-08-28 19:31 x42 Note Added: 0024978
2020-08-28 20:10 Dirk Offringa File Added: ardour click plus DN click.JPG
2020-08-28 20:10 Dirk Offringa Note Added: 0024979
2020-08-28 20:46 Dirk Offringa Note Added: 0024981
2020-08-29 22:51 Dirk Offringa Note Added: 0024982
2020-08-30 23:24 x42 Note Added: 0024990
2020-08-31 06:23 Dirk Offringa Note Added: 0024992
2020-09-01 09:19 Dirk Offringa Note Added: 0024997
2020-09-01 10:08 x42 Note Added: 0024998