Forums
If we connect the same audio source to multiple input buses, changing the gain on the first one will affect the subsequent ones. It's as if they were nested, related in order of creation, with the first created buses acting as parents of the subsequent ones.
It behaves like a serial signal, not a parallel one.
It does not occur if the audio sources are different.
While this isn't dysfunctional, it does exhibit abnormal behavior. It may be a symptom of a hidden bug.
File attachments
re. Abnormal behavior in input buses...
hi, good catch...
maybe a feature that has been there for ages, in fact since the very beginning almost 20 years ago.
it probably relates to the fact that when you connect the all input buses share the same signal buffer from the same source jack-audio port source if connected in parallel, so the bug-feature is thus a shared one between jack/pipewire and qtractor :)
of course it may have a workaround, implying a simple code change that will copy the source into every and each input bus buffer, adding some processing overhead directly proportional to the number of inputs buses in place. (EDIT: this would need to run all-the-f**king-time, as long there are input buses, connected or not and no matter if on playback, recording or else, so I'd say the fix would rather be a pessimization :)).
so the question is, is it worth it?
thanks
Just an intuition
What I'm about to say next probably doesn't make sense, but...
What if the "zero copy" problem lies behind that shared buffer optimization?
Whether it's worth checking or not is not my decision :)
re. Just an intuition...
it ain't an optimization, rather about the same physical buffer that's being read and acted upon (ie. gain+panning) by qtractor processing itself...
nothing to do with the so called "zero-copy" optimization, where an output port buffer is made physically the same as an input port buffer, saving a copy operation in the jack/pipewire graph: not an optimization that qtractor or any jack-client can circumvent per se, though.
cheers
However, there's something I'll never understand
In other jack programs (Ardour, non-mixer, etc.), the zero-copy problem doesn't manifest itself when you directly connect their own bus inputs and outputs. I remember you could get nasty feedback if you did things carelessly... but the audio never cut out.
And that leads me to two possible reasons:
1- It's not a zero-copy problem.
2- If it is, those applications have a way around it.
I'm just sharing thoughts that may be wrong. I have no knowledge of all this. So sharing these thoughts isn't helpful either... but I felt the need to express them.
Greetings
New experimental [xcopyinbuf] branch...
ok,
this boils down to fix the Abnormal behavior in input buses, and as said, there are, there will be a reasonable price to pay for the fix, even tough is a simple one in code...
so please, check out qtractor >= 1.5.4.11git.f69c33 [xcopyinbuf] branch
please test run and tell if it significantly hoses the cpu/dsp load in any case; importantly to try or test it with your most awesomely bloated sessions, and then compare with the regular builds...
please tell if the said price is too significant... not on simple sessions (few input buses) but might be a lot on the big ones that matter ;)
wholly much appreciated.
thanks ahead.
Test on pipewire
Much worse now regarding the Zero Copy issue.
However, it fixes the strange behavior I started the thread with.
In the regular version of Qtractor:
1- You can directly interconnect inserts as long as you do it in the correct order.
2- You can directly connect bus outputs to insert inputs.
In this version:
These direct connection exceptions no longer apply.
It now only works in strictly recommended mode.
No direct interconnection will work unless you use an intermediary.
If you use this rule, there are no issues:
1- Buses should only be connected to hardware inputs and outputs.
2- Inserts should only be connected to external applications from Qtractor.
3- Auxiliary sends are used for internal Qtractor interconnections.
But this rule leaves out cases, for example, recording a bus output on a new track. Interconnecting tracks.
It's a good rule to create a reliable environment for people new to Qtractor who encounter this problem. But I think the logical thing would be for the problem not to exist and to be able to organize the flow freely.
I consider this a step backward.
The good thing is that we've verified that how this is organized directly influences the "zero copy" issue, and suggests that a solution may exist.
An interesting fact
In the official 1.5.4.
If you have a duplex bus with the monitor enabled, and you connect the output to the input of another bus, the monitor signal is sent without any problems... however, the bus's own signal from the tracks is not sent.
Why is one signal output and the other not output? Shouldn't both be affected equally if they are output from the same bus?
and one more
And there is another effect. Having a bus that outputs to the master input bus shows that the signal is silenced as soon as you insert an AUX send to the master bus, even when the AUX send is not activated. The silence is permanent for the session. Removing the AUX send or reconnection the bus's output to master input doesn't break the silence.
This applies both for main and xcopyinbuf.
EDIT: yes, I know that connecting a bus to master input isn't recommended but maybe this information helps a bit.
no big CPU penality if any
On my old Core i7-7700T and jack2:
= distributed project with lots of plugins (especially reverb) in non-mixer-xt =
jack-bufsize: 128
In both cases Qtractor CPU load 30%, realtime CPU 50% with main, 55% with xcopyinbuf
= monolithic project, Qtractor only =
jack_bufsize 1024
In both cases Qtractor CPU load 74%, realtime CPU 70%
So a little difference was seen with bufsize of 128 and many connections between Qtractor and non-mixer-xt, and it was 10% which might be within the accuracy of my ad-hoc-measurement.
I don't see any show stopper.
re. no big CPU penality if any...
ok, thanks a lot
but, as mentioned specifically, the penalty may raise proportionally with the number of audio input buses...
please focus on that scenario: do you have heavily loaded sessions that depend on a significant count of input buses?
remember, it doesn't matter how many tracks, plugins, outputs--ofc. the much the better to assess the situation--input bus count is what it's at stake here...
seeya
Do INSERT returns count?
Since many buses have an INSERT send and return to and from a non-mixer-xt strip I'd have many input buses if INSERT returns count as input buses.
But I don't have multiple connections to each INSERT return.
re. Do INSERT returns count?
oh yes, insert returns count as an input bus!
there probably will be a difference if there are several insert returns and/or regular input buses fed or connected from the same source; in [xcopyinbuf] all these will be isolated or independent (as they should), while in [main] or [develop],... it proverbially depends... ;)
cheers
but ...
I recorded the project with the many connections to non-mixer-xt. The connections were always in a bus: an insert send to a non-mixer-xt strip and back.
It was not identical, although I am unsure if my ears can hear any difference reliably.
Maybe that's exactly what was expected, Rui?
EDIT: Dragonfly Reverb's reverb didn't null, either, while Klangfalter's reverb did. No explanation for that.
I see no show stopper, though.
re. but...
not sure
does it have several input buses that connect to the very same source? and one of them, not the last in create list order, has different gain, pan and/or any audio_fx plugins activated (in at least one of those input buses)?
then, for sure, you'll fall into what the OP called Abnormal_behavior_in_input_buses that we're trying to assess/fix and results might certainly differ between [main/develop] and [xcopyinbuf] builds.
seeya
no
In this case, no. But it seems is has some slight side effects.
forget about the not nulling out
Since there were 2 recording runs it's expected that algorithmic reverbs and synth plugins output a slightly different signal.
and the bottom line is...?
the first question remains: is it worth it?
cheers
No, it wasn't worth it
(It wasn't what was causing the damn zero-copy error.)
I just discovered the LSP Send/Return plugins.
They solve all connectivity issues.
Here's how it goes:
1- The input buses are intended for recording audio, not for mixing. They are Qtractor's recording ports. They should not be used for any other purpose. They do not support recording from Qtractor itself session, only from external hardware or applications.
2- The output buses are intended as Qtractor's playback ports. They are used to connect Qtractor to playback hardware (speakers), or to be played back in other applications or hardware (mastering, recorders, etc.). They are not intended for mixing. If you send them to an insert for this purpose, they may work, although they most likely won't.
3- The inserts are intended to mix Qtractor's internal audio with external applications or hardware. They can be inserted anywhere in the plugin chain. They're not designed to be directly interconnected. If you do, they may not work. They have a latency of one sample cycle, which in many cases is negligible.
4- The aux sends are designed to send and mix signals within Qtractor, from track to output bus and between buses. They work wonderfully with no delay or latency.
5- For other purposes, use the LSP-Send/Return plugins. These allow you to send signals between tracks for mixing, record an output bus into an input bus in Qtractor, etc.
As @bluebell says, a "how-to" should be written that explains these points as clearly and simply as possible. As soon as I have it, I'll present a draft.
It's a way to solve the zero-copy problem.
But this means losing the functionality of the faders on the output buses again... So even though it's not recommended, as long as it works, I'll continue using bus a > inserts to connect the buses intended for mixing, and I reserve the aux sends for buses intended for effects. This gives me the perfect experience with full fader and volume control functionality.
Everything points to an internal bug in Qtractor... and the real solution is to fix it.
But if we can't detect it, the "how to" is a compromise solution. I can't program, but I can write well (at least in my language).
Yea, the bus -> insert…
Yea, the bus -> insert strategy has resulted in the best workflow so far. I hope we're not talking about disrupting that.
re. the "zero-copy" connundrum...
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?
Rename INSERT to EXTERNAL?
So wouldn't it be better to rename the INSERT sends and returns to EXTERNAL sends and returns to clarify the purpose of the INSERT sends and returns?
re. Rename INSERT to EXTERNAL?
they are actually INSERTs in terms of the plugin chain, ain't them?
Add new comment