pipewire goes xrun-happy if default.clock.rate is not 48000, regardless of all other factors
So I've been struggling to match stability of my pipeline's configuration under pipewire to jack2. First major obstacle turned out to be #724 (comment 823717) - overestimated automatic quantum selection.
Recently I figured out the second major obstacle: it's dropping xruns between all nodes (especially compressor and limiter) like crazy if rate is default.clock.rate=192000 regardless of node rates. In fact, it gets worse if I force rate=48000 via node.latency/audio.rate in either pre-hardware virtual interface in pipewire.conf or JACK nodes in jack.conf (or the same via envvars). 48khz processing should be easier but in 192khz PW mode with 48khz nodes it's raining xruns in thousands and LV2 GUI graphs for some reason run faster (I assume that 4x rate). In 192khz PW mode "wait" for hardware nodes and "busy" for software nodes ~4 times bigger than in 48khz PW mode, even if 48khz node rate is forced for them (meaning that they have those big wait/busy times with small, 48khz-based quantum sizes which makes them fail miserably).
Setting default.clock.rate=48000 in pipewire.conf (and not jack.conf even thou pw-dump
shows it being applied) allows me to even go back to using all 8 bands in LSP compressor. In addition to that, pw-top
, with which I monitor xrun rates, is completely our of whack in general: it shows hardware nodes with 48khz rate when they run in 192khz (based on pw-dump
and /proc/asound stats), sometimes it shows all-0 or weirdly small values when both USB and build-in HDA DACs are used simultaneously for same pipeline and sometimes it just permanently hanging. pw-top
100% guaranteed to hang when BT headphones are connected even though everything works fine.
But even in "stock" 48khz configuration (and if default.clock.rate in pipewire.conf is 48000 when other rates are nowhere to be found in pw-top
even if they are set in different configs, including hardware defaults) performance is far from jack2's. I still blame lack of configurable period number (mainly, 3 versus 2) for that. Keep in mind that jack2's pipeline performance is MUCH more stable (12ms without xruns versus "anything lower than 1024*2/48=42,(6)ms is a disaster") in "obsolete" "sync" mode, activated via --sync
option, rather than default "async" mode.
I assume that a lot of issues with JACK apps comes from all that. Such as some from #1265 (closed)