is not being taken into account just because we're dealing with input (recording) latency compensation alone...
getting it to know whether you're recording a full round-trip signal is hard, to say the least; it can only assume you're recording an external input (mic, line-in, etc.) or from an internal app/client that is connected in... and not anything that you may send to line-out then feedback to line-in, and account for the whole round-trip anyway.
qtractor, jackd or pipewire for that matter, can only guess or better estimate the input/capture latency because that's the only graph path it may only know for sure (from where it's being fed anyway)
hth.
ps. in you particular case then (jackd) you may please tinker with the -I parameter alone: say -I 160 ?
is not being taken into account just because we're dealing with input (recording) latency compensation alone...
getting it to know whether you're recording a full round-trip signal is hard, to say the least; it can only assume you're recording an external input (mic, line-in, etc.) or from an internal app/client that is connected in... and not anything that you may send to line-out then feedback to line-in, and account for the whole round-trip anyway.
qtractor, jackd or pipewire for that matter, can only guess or better estimate the input/capture latency because that's the only graph path it may only know for sure (from where it's being fed anyway)
hth.
ps. in you particular case then (jackd) you may please tinker with the -I parameter alone: say -I 160 ?