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.
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.
Add new comment