first let's get this whole topic renamed to "self-connection" recommendation or advice (not)...
second, there are two sides to explain this fundamental bug, optimization, phenomenon, restriction, constraint, whatever you may call it...
but foremost, the so called "zero-copy" optimization is not really the root-cause of all the troubles we've been dwelling here and for ages--it just happens to been tagged that way.
so bear with me...
now, the true "zero-copy" problem is mostly, if not exclusively, due to genuine jackd; pipewire pre-1.0.0 used to resemble it too, but not anymore--for good reason, I'd say.
let's continue...
the major culprit is, as ever been from the start--and please stress this reasoning from now on, please--is in fact the order which qtractor runs its internal processing (in a single DSP processing cycle, to be true-to-the-bone).
in summary:
it first reads all inputs first;
process all the routing to tracks and plugins;
then all results are routed to respective outputs.
quite boring and standard computer processing isn't it?
of course, you may now realize, that this signal flow won't ever make those outputs data available to the (1.) inputs, at least in the same process cycle.
but there come some devilish strangeness that may may happen in the details (read in the infrastructure aka. jackd or pipewire...)
all that to conclude, with my lousy DSP engineer hat on, that [xcopyinbuf] is probably the most correct and safe implementation to the whole mess.
but then, the proverbial YMMV may reason your stance otherwise. :)
wholly cheers!
ps. and what about those other jack-applications not having the same self-connection trouble?
ardour - its internal processing its dang sofisticated to explain here, but it can be mansplained as having its own internal jackd/pipewire subsystem of its own (well, historically speaking it is/was the real-mccoy predecessor of jackd, don't you know?)
non-mixer - each strip is a stand-alone jack-client, so case dismissed. :)
hi all,
first let's get this whole topic renamed to "self-connection" recommendation or advice (not)...
second, there are two sides to explain this fundamental bug, optimization, phenomenon, restriction, constraint, whatever you may call it...
but foremost, the so called "zero-copy" optimization is not really the root-cause of all the troubles we've been dwelling here and for ages--it just happens to been tagged that way.
so bear with me...
now, the true "zero-copy" problem is mostly, if not exclusively, due to genuine jackd; pipewire pre-1.0.0 used to resemble it too, but not anymore--for good reason, I'd say.
let's continue...
the major culprit is, as ever been from the start--and please stress this reasoning from now on, please--is in fact the order which qtractor runs its internal processing (in a single DSP processing cycle, to be true-to-the-bone).
in summary:
quite boring and standard computer processing isn't it?
of course, you may now realize, that this signal flow won't ever make those outputs data available to the (1.) inputs, at least in the same process cycle.
but there come some devilish strangeness that may may happen in the details (read in the infrastructure aka. jackd or pipewire...)
all that to conclude, with my lousy DSP engineer hat on, that [xcopyinbuf] is probably the most correct and safe implementation to the whole mess.
but then, the proverbial YMMV may reason your stance otherwise. :)
wholly cheers!
ps. and what about those other jack-applications not having the same self-connection trouble?