|
|
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). |
|
|
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. ardour midiclock latency.JPG (54,434 bytes) |
|
|
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! |
|
|
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. |
|
|
I just spent over an hour typing in a detailed report bu my session expired and all was lost. |
|
|
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) |
|
|
"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) |
|
|
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. |
|
|
"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 |
|
|
"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) |
|
|
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. |
|
|
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. |
|
|
Ok, let me know If I can some more. I appreciate your implication, thanks for this! |
|
|
" 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. |
|
|
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. ardour click plus DN click.JPG (23,289 bytes) |
|
|
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! |
|
|
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! |
|
|
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. |
|
|
Hey that's good news! So my findings were correct.... that's reassuring. Thanks! |
|
|
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! |
|
|
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). |
|
|
OK. I have finally got my hands on a [remote] Windows system that has a dongle to tap-off the outgoing MIDI signal and send it back to an audio-port. I found various small bugs related to systemic latency configuration for PortAudio/ASIO and WinMME MIDI Ports. The MIDI Clock generator was also updated to use the new Tempo Map. Since Ardour 7.4.285 (Mixbus 9.1-153) MIDI clock is sent reliably. On Win 11 with an AudioBox at 48KHz there are about +/- 20 samples jitter. |
- Anonymous
