Hi, I just noticed something strange. I have a custom jack-client-rules.conf file in my .config folder that specifies the quantum and sample rate (e.g., 128 / 96000) with which Qtractor should launch. I found this very convenient because it allows me to avoid having to set the entire system to a specific value using the Cable app before starting the DAW. Actually, this method has previously only worked with Qtractor and Hydrogen, whereas it never worked with Ardour or LMMS, for example.
Now, when I start Qtractor, I can see that the specified values are correct (128 / 96000 in my case), but when I open a project containing an audio recording, it doesn't seem to play back using those settings—even though those are the values specified in the config and the ones used for the original recording. The audio file only plays back correctly once I launch Cable and enter the exact same quantum and sample rate values that are already visible in Qtractor.
This wasn't the case before. I'm running MX Linux. Naturally, I also have a custom pipewire.conf file.
I realize the causes could be varied, but it might be a bug, so I’m sharing this here.
Regards!
I just checked on…
I just checked on EndeavourOS (Arch). Same PC (dual-boot), same interface, same plugins, same project, same .config files—and the same problem.
The PipeWire wiki states that the following line is sufficient:
node.latency = 128/96000
However, Qtractor behaved strangely in that case and started up with the wrong settings—specifically 64/96000.
I was able to fix that back then by adding an extra line:
node.latency = 128/96000
-> node.force-quantum = 128 <-
This wasn't necessary for Hydrogen, for example.
The new problem I described in my last post can also be resolved by adding yet another line:
node.latency = 128/96000
node.force-quantum = 128
-> node.force-rate = 96000 <-
Ultimately, I can't say for sure whether this is an issue with PipeWire, Qtractor, or both.
Regards!
re. Qtractor settings for PipeWire in .config...
neither do I
but one thing I know on PipeWire (PW): you can run each node in the graph at different latencies (quantum/rate); most of the time, in default PW configurations, these latencies are automatically managed by PW, specially taking hardware device capabilities into account, to keep the whole graph run stable and sane (and avoid systemic xruns as much as possible)
now, qtractor uses the JACK API (not the native PW API) so it relies on the PW-JACK substitution to run under PW and not genuine jackd(bus)
all nodes of the PW-JACK graph are supposed to run at the same single latency setting at any given time; however the latency setting is not perfectly still over time and may change when the last jack client application terminates and leaves the graph and/or change again when one first enters the PW-JACK graph...
and that's mostly why forcing the quantum and rate at the PW(-JACK) config, as you've done above, just solves the/your problem.
but, take note that if some device, any device, doesn't support the quantum (buffer-size) an/or (sample-)rate you're imposing then PW may incur into re-buffering delays and resampling thus affecting the overall perceptual latency and system processor load resp.
proverbial YMMV.
cheers
I will keep the current…
I will keep the current configuration and hope that the problem does not recur in the long run. Thank you for the explanation!
Best regards!
Add new comment