I’ve checked on the MBus site without response. Perhaps this is a better place.
I reference a previous post of Paul’s (thanks for that) sharing that "Latency compensation works by delaying track playback. "
From a perspective of audio I/O, will signals going into the interface, being processed, leaving the interface, thusly have NO plugin delay compensation applied? I see that maybe only things that Ardour plays back from disk get compensated.
thanks
h
This is entirely out of date now. Ardour’s latency delay compensation was the subject of a Ph.D thesis. There are delay lines all over the place, and some very complex design. Everything is fully latency compensated.
@x42 will likely chime in to correct me.
Nothing to correct.
The state that OP describes was how Ardour worked until version 5, before full latency compensation was implemented in Ardour 6.
Great. I get that playback is no longer the basis for compensation, but what is the new/current basis for compensation. From Ardour’s perspective, and maybe by extension MixBus, what is the root assumption behind whatever the current architecture achieves? Tools like MainStage and Gig Performer need a particular timing model, and record/play/mix apps may need something different. I am trying to understand what is actually implemented, and how potentially to use whatever settings/preferences are provided to manage timing properly.
Additionally, (from the MB forum) I understand that there are some departures from Ardour’s timing model that have been imposed that lead to recommending some particular workflow constraints. I want to understand those better, but it seems useless without understanding the foundation that MB. has been built upon and how it may or may not match many of the posts I’ve been reading.
thanks,
h
You can read Robin’s Ph.D thesis (I think). or you can accept that Ardour doesn’t need any work on your part to get latency compensation correct.
The only situation where you need to think about it is when you create multiple signal routes from one point to another point and those routes have different latencies (e.g. different plugins in two aux busses). Ardour cannot “correct” that situation because there is no correct answer.
If you avoid routing ambiguities, everything Just Works ™ and you do not need to think about it.
…but is it possible to know what Ardour chooses to compensate vs what is left alone?
nothing is left uncompensated.
There are no differences between Ardour and Mixbus either.
Playback is aligned to physical outputs depending on port connections: how long will it be until the signal reaches the edge of the graph (or if you calibrated systemic latency: until it reaches the soundcard’s outputs).
If you use JACK/Pipewire, you can inspect this with jack_lsp -l
the compensation can be zero samples, though, correct?
yes, if there’s no latent plugin anywhere, nothing needs to be compensated for.
playback still pre-rolls (fill buffers) to align to physical outputs though. So that when Ardour’s (or MIxbus) clock shows 01:00:00:00 you hear the corresponding sample on speakers.
I am less concerned about playback related material, and more specifically I/O and paths. According to Ben, there are MixBus and non-MixBus paths and are timed differently. Perhaps this is also a legacy comment, but not nearly as aged as Ardour 5 or 6.
While I understand the urge to push the “just works” approach, I am more interested to know in which situations things will just work and in which situations things are optimised toward playback vs signal flow.
That use to be the case before Ardour 6 was merged into Mixbus. IIRC back then major versions aligned.
MIxbus sends always had delaylines so that latent Fx in Mixbusses can be compensated for, before Ardour aux-send supported it.
Proposed rule: if you’re reading about Ardour online, and the date is more than 12 months before the day you’re reading it, be willing to discard everything you read.
That’d invalidate the Ph.D. thesis too 
Luckily there is still recent source code available 
1 - Ben’s guidance is 2025 Jan, so not exactly old. While I am willing to disregard, by virtue of this post I am seeking to gain a better understanding.
2 - Even more recently, Dingo’s guidance (consistent with the current MB user guide) is to stay away from the Audio Connections system and just use MixBus’s GUI knobs for paths.
3 - The basis for this post is to determine to what extent “playback” of audio has a role in compensation VS to what extent overall I/O consistency has a role in compensation. This seems not covered in the manual.
4 - I have and do encounter issues with routing/summing in MixBus that I do not encounter in Ardour.
h
On Delay Compensation & Recommendations for Routing is still a good overview
and yes, that’s also what Dingo echoes:
Yes, great overview, and part of the basis for my repeated question. As this is playback-related, I am interested to know if all delay compensation is playback related. While my quote from Paul may be quite old, my question remains.
Dingo’s post as recently as December says sending a MixBus back into the system is problematic. I agree. Doesn’t sync with the “just works” claims.
I seek to understand thing better with respect to how Ardour is designed to handle signals, as opposed to playback.
I expect this is true. I want to know what the basis is for the compensation.
The latency reported by processors (mostly plugins) and hardware “ports” that exist in the signal routing.
Isn’t that just another way of saying don’t connect outputs back to inputs because it creates a feedback loop?
Can you explain the distinction you are trying to make? Are you trying to make a distinction between audio which originates from a file on disk vs. audio which originates from the audio interface inputs?
There is no distinction; you can change In/Disk monitoring any time regardless of transport state.