This is the opposite of a complaint – I was overjoyed to discover this morning that Aux Sends don’t seem to require additional Jack connections. But I’m wondering how that can be.
My workflow is to use Ardour (6.5, under Debian 11) to do initial routing and then verify things with Qjackctl (and sometimes do stuff there too). I was dreading a project where (for the first time) I need to provide custom monitor mixes to a group of musicians and fell headlong into all the cool capability of Aux buses to do that.
But… but… when I added all the sends and then went to Qjackctl to verify the routing… there’s no change. But… but… they work great! It’s like magic. and in fact leads me to believe that I can delete a bunch of Jack routes and replace them with better use of Aux sends. But… maybe I’m dreaming? Maybe the Jack routes are there but Qjackctl doesn’t see them? I refreshed/restarted Qjackctl and it still doesn’t see them.
This definitely falls in the “don’t look a gift horse in the mouth” department, but I’d kinda like to know what the system-load tradeoffs are with this magical stuff that’s happening. Thanks in advance for clues.
That is entirely intentional. Aux sends are Ardour internal by design.
In short: JACK is designed for inter-application routing, and not a substitute for intra- application routing.
There main reason why aux-sends are internal to Ardour relates to JACK’s architecture:
JACK only provides mechanism but does not enforce policy
JACK only passes data around without any processing (except summing)
While these decisions are brilliant for inter-application routing they are less useful for signal flow inside a DAW.
Aux-sends should only connect downstream: track → bus → busses, and not allow loops. This allows for tracks to be processed in parallel and also provides a sane signal flow.
It must be possible to use many aux-sends (one to many connections) without breaking latency compensation.
Those are in direct conflict with JACK.
The former implies a connection policy, while JACK allows for arbitrary connections.
The latter cannot be done with JACK port connections: Latency compensation requires a delayline per send/return pair. JACK can only inform clients about port-latency (pass data around) but must not alter the data. One-to-many connections require a “delay in the wire” (per connection pair), which JACK does not provide by design.
None really. In both cases memory buffers are passed around (or rather pointers to buffers and offsets). It is not a technical reason that aux-sends are internal, only a conceptual difference.
A further question: I’ve discovered Foldback. I grok that it has a different UI. But is there a functional or performance difference between using Aux busses vs Foldback busses, or is this another instance of “none - just buffers being passed around”?
Copied here so you don’t have to leave to look up that post:
There is nothing wrong with using regular busses for personal monitors, except it is usually less convenient.
Sends to busses are configured on the source-side, while Foldback channel-strip shows all sends on the destination side. This makes it easier to configure levels for each musician’s monitor.
Sends to foldback-busses do not clutter up the processor-box on the source-track.
Soloing a regular bus also solos up/downstream tracks or busses and mutes other tracks. Foldback sends are not affected by mute/solo (depends on mute-point configuration - Preferences > Signal Flow, or right-click on a mute button).
It is less confusing if you use busses for sub-mixes, especially if you use a control-surface. Foldback busses/sends show up separately.
Foldback send panners (on stereo foldbacks) are by default not linked to the track’s panner (right-click on the foldback’s panner to link)
Foldback busses only take up a single strip’s worth of mixer screen estate.