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
_______________________________________________
Linux-audio-user mailing list -- linux-audio-user@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to linux-audio-user-leave@xxxxxxxxxxxxxxxxxxxx
