That's just a case of old documentation still floating around. Install QPWGraph instead of Qjackctl. Problem solved. Ardour works great with PW-Jack.
qpwgraph doesn't handle all the usecases that qjackctl does: it only provides the patchbay bits. I don't think there is a widely-accepted PW GUI tool for doing things like:
changing the sample rate for all JACK clients (so that they don't waste cycles up-and-down-sampling all over the place);
starting / stopping / seeking the JACK transport;
starting clients (the "Session" button in qjackctl), versus configuring their connections (I don't use this bit myself).
Agreed that this is one area where PW admittedly needs some work. There are a few utilities floating around, but nothing included in standard distros. I'm using this: https://github.com/cyber-sushi/pipewire ... ate-config
But admittedly, as a Python script, rather than a complied app with an easy installer, it's probably harder to use for most people.
While it's possible to make a utility that changes the buffer size and sample rate globally for everything until you change it back to a dynamic setting, I think it would make more sense to have the app control the buffer size and rate.
For example, ardour has a buffersize setting in the audio config, you change it and it becomes the new buffersize globally. You quit ardour and it goes back to the previous (dynamic) setting. You start guitarix and change the buffer size in the menu and it takes effect until you quit guitarix.
With JACK you can't change the samplerate but the pipewire API has a jack_set_sample_rate() extension you can use with the expected results. Your saved project in ardour with the wrong samplerate will simply (ask if it can) change the graph rate and there is no need to change anything globally (and then forget you changed it and have a bunch of non-pro audio stuff needlessly have to resample).
I think this also matches how you would use an ALSA or other backend in a DAW.
...just for my understanding: pw sets latency on a client base?
The PipeWire buffer size in the graph is the same for all clients. Client can each make a suggestion about their preferred latency and PipeWire will configure the minimum latency of those suggestions. PipeWire does not attempt to have a different buffer size per client or do anything fancy to group buffers or wakeups.
If a client asks 64 sample buffers and another 1024, the graph is using 64 sample buffers and the one asking for 1024 gets woken up every 64 samples as well. If it can't produce 64 samples, it can do its own buffering (like what the ALSA plugin and pulseaudio emulation do by placing a ringbuffer inbetween the app and the pipewire graph). But JACK clients all run at the same buffer size in the graph, just like JACK.
...just for my understanding: pw sets latency on a client base?
If a client asks 64 sample buffers and another 1024, the graph is using 64 sample buffers and the one asking for 1024 gets woken up every 64 samples as well. If it can't produce 64 samples, it can do its own buffering (like what the ALSA plugin and pulseaudio emulation do by placing a ringbuffer inbetween the app and the pipewire graph). But JACK clients all run at the same buffer size in the graph, just like JACK.
...so then it's not in sync with the 64 sample buffered application? That's just a few mSec, which is acceptable in one turn (from a musical perspective, but not from a technical one).But in a possible second turn the different latencies will show their ugly faces... or did i get something completely wrong?
Currently working with https://www.honeysuckers.rocks/?lang=en
Fiddling with sequencers does not evolve into music necessarily and Mac users have smelly feet and guzzle little children.
...just for my understanding: pw sets latency on a client base?
If a client asks 64 sample buffers and another 1024, the graph is using 64 sample buffers and the one asking for 1024 gets woken up every 64 samples as well. If it can't produce 64 samples, it can do its own buffering (like what the ALSA plugin and pulseaudio emulation do by placing a ringbuffer inbetween the app and the pipewire graph). But JACK clients all run at the same buffer size in the graph, just like JACK.
...so then it's not in sync with the 64 sample buffered application? That's just a few mSec, which is acceptable in one turn (from a musical perspective, but not from a technical one).But in a possible second turn the different latencies will show their ugly faces... or did i get something completely wrong?
Those async APIs have a function to query the delayed samples, ALSA has snd_pcm_delay() and pulseaudio has pa_stream_get_latency() to sync with the graph cycles.
I would rather discussion on Pipewire 1.0 continue in the new topic. While this one has some good information it also has quite a lot of misinformation and misinformed opinions.
Clean slate FTW!
That is a very informative article you found! It gives us a good idea as to where Pipewire is right now, and where it is going. It looks like even though the most important stuff is there, there is still a lot of polishing and a lot of extra things that they'd like to further add to Pipewire.
We’ve also recently started implementing the last missing pieces of JACK, which is NETJACK2 support and a firewire audio driver called FFADO. The FFADO support likely needs some more work because we have not been able to actually test this because we don’t have the hardware.
Yeah, the only bit of performance problem I have is specific to firewire using JACK. I have a Focusrite Saffire Pro 40. Live monitoring out of the Focusrite adds more latency than using the onboard sound on my motherboard. For instance, if I have the signal chain:
Guitar Plugged in to Focusrite > Carla with some effects > Focusrite out to speakers
There is an audible latency when the buffer is set to 512. As opposed to
Guitar Plugged in to Focusrite > Carla with some effects > On board sound chip out to speakers
where it is fine.
Edit: This wasn't to do with pipewire, I needed to add threadirqs to my grub options.
Last edited by Largos on Mon Feb 26, 2024 2:21 pm, edited 1 time in total.
I would rather discussion on Pipewire 1.0 continue in the new topic. While this one has some good information it also has quite a lot of misinformation and misinformed opinions.
Clean slate FTW! :wink:
