Hi LAU, I have now switched to pipewire on my main laptop, with an overall positive experience especially JACK-aware applications typically working 'out of the box' and (more or less) co-existing with other 'desktop' applications (I might talk about some caveats in a different thread). Something which I still can't totally work out though is jack frames/period (aka buffer size aka 'quantum') and its management. For 'everyday' use I keep this at 1024 (which I think is the default) but in some cases I want to push it down even to 128, and I must say that with recent versions of pipewire and with a reasonable 'cpu settings' (I have a tuxedo machine and it has its own cpu thingy) this actually works quite well. What I'm still not understanding completely is how to best manage the frames/period setting. Pre-pipewire in this use case I'd have dedicated qjackctl presets and just select the desired frames/period one for the sound device of interest, restart jack and be good to go. Now with Pipewire it seemed that this would be handled via pw-metadata and setting the clock.force-quantum value (I even made myself a script and then a little python-tk 'gui' for this and setting the sample rate). Up to recently indeed all of the previous preset-related settings in qjackctl (most notably sound device, sample rate, frames/period and periods/buffer) where disabled, but then now _only_ the frames/period setting dropdown seems to be available again and selectable. And indeed jack software (e.g. Ardour) seems to report that buffer size set in qjackcrl. But then if I do: pw-metadata -n settings 0 I see 1024 for clock.quantum and 0 for clock.force-quantum Explicitly setting clock.force-quantum also works. So I'm a bit confused. It seems the idea is to be able to change buffer size 'on the fly' or at least without restarting applications (e.g. in Ardour I _did_ have to disconnect and reconnect to JACK-pipewire, but without closing/reopening). Then I remember lots of discussions and advice about setting, for instance, the periods/buffer to 3 for USB sound devices etc. etc. With Pipewire we don't care about this any more? I also had a couple of instances where Ardour complained about the session being at 48000 but jack running at 44100 when actually it was running (reportedly) at 48000 - but then this is another matter, maybe. Hopefully getting insight on this could be helpful to other LAU 'transitioning' to Pipewire[-jack] :-) Lorenzo