Allow running scripts under PipeWire

[v-fox]

I've migrated to PipeWire from PA & JACK combo and managed to achieve stable work with post-processing via LV2 plugins in JACK hosts using qjackctl for auto-routing. However, there is still one major trouble: qjackctl does not want to launch the script that launches these hosts because it only does so while launching jackd and, since there is no jackd anymore which was replaced by libjack substitution, it doesn't want to do so.

See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/698 for details of the setup.

[rncbc]

sorry but that seems a little bit out-of-scope to qjackctl.

when under pipewire's libjack substitution, qjackctl acts as a normal JACK client, showing the "Active" mode on main display. in this mode of operation qjackctl does not handle any aspect of the JACK server (jackd) or service (jackdbus) whatsoever, so it doesn't "know" when to launch the startup/shutdown scripts anyhow.

also, you can start and stop or quit qjackctl anytime, rinse and repeat... it will be always just a regular JACK client, in very same way...

you'll have to resort your question to the pipewire devs. then ask whether there are any hooks or configuration that you may do to "emulate" the qjackctl startup/shutdown scripts.

[v-fox]

sorry but that seems a little bit out-of-scope to qjackctl.

PA and JACK are planned to be deprecated and replaced by PW in distributions.

in this mode of operation qjackctl does not handle any aspect of the JACK server (jackd) or service (jackdbus) whatsoever, so it doesn't "know" when to launch the startup/shutdown scripts anyhow.

"When" is literally on startup, regardless of JACK state.

you'll have to resort your question to the pipewire devs. then ask whether there are any hooks or configuration that you may do to "emulate" the qjackctl startup/shutdown scripts

Or you could just allow running the startup script unconditionally at startup.

As for "emulating the qjackctl startup/shutdown scripts", I propose to PW that qjackctl should be replaced by own session manager with state saving and routing rules.

[rncbc]

PA and JACK are planned to be deprecated and replaced by PW in distributions.

that would be a bold move, specially re. JACK (i don't care about PA, it is the one to be deprecated for sure; not sure about JACK... PW is still a long way to be on par to JACK in pro-audio production terms, if ever :) PW is good-enough as for general desktop-audio though (which is PA scope)

the moment that distros ever enforce me to replace JACK for PW, i'll ditch PW on the spot... :)

Or you could just allow running the startup script unconditionally at startup.

or you could just have a custom script doing exactly what wish, wrapping the qjackctl launch eg.

1. run the pre-startup script commands first...
2. run qjackctl...
3. run the post-shutdown script commands last...

how hard is that? :)

[v-fox]

that would be a bold move, specially re. JACK

JACK was in "maintenance-only" mode for years now, just like PA. Despite several proposition, including ready patches, it's stuck being able running on single DAC per server only which is not the case for PW which also allows transparently using arbitrary buffer sizes and rate for any node. Which is nice.

PW is still a long way to be on par to JACK in pro-audio production terms, if ever :) PW is good-enough as for general desktop-audio though (which is PA scope)

I'm sure that PW dev would be glad to hear the exact list of things that PW is lacking in comparison to JACK.

or you could just have a custom script doing exactly what wish, wrapping the qjackctl launch eg

Have a wrapper script for a thing that launches wrapper scripts ? It's easier to autostart a GUI app with desktop-file in DE than scripts, especially for "normal" users that are not fond of CLI.

I can manage but I don't want to advise the same to every other user.

how hard is that? :)

How hard is to lift artificial undocumented limitation on supposed "startup" scripts in qjackctl ?

[rncbc]

How hard is to lift artificial undocumented limitation on supposed "startup" scripts in qjackctl ?

as hard as is not quite a limitation but it's fit to purpose which is about being exclusive to the genuine JACK server or service startup/shutdown.

what PW does is implementing the JACK API, quite artificially in this regard; it does NOT try to emulate nor implement a JACK server or service, control protocol and life-cycle, which are in fact the natural scope of qjackctl setup settings and its scripting hooks.

[v-fox]

as hard as is not quite a limitation but it's fit to purpose which is about being exclusive to the genuine JACK server or service startup/shutdown.

jackd isn't even a systemd-service and jackdbus is kind of a failed experiment. Last time I tried the latter, qjackctl couldn't apply all of settings to it (don't remember which ones exactly). jackd has --sync option that's undocumented in man jackd and gives me 3 times lower stable latency than what I could achieve without it. So it's not all rainbows in jackd land either.

AFAIK, jackd doesn't have some kind of socket that would be used for communication other than libjack substitution. And if jackd binary would be emulated then libjack would have to be emulated anyway too. Or PW had to keep full API compatibility between them. But being 100% API compatible was newer PW's goal as JACK's API itself is limited and only focused on some parts of audio handling. It's not a flawless ultimate achievement.

The goal is to launch JACK apps and get audio from them, that works. But jackd doesn't have its own session handling either. It has to rely on external tools just like PW. jackd will newer have the kind of automation that PW aims at by not limiting to boundaries of either JACK or PA API where former doesn't even define channel maps for ports. Automatic routing of surround setups based on port tags and properties under JACK is unthinkable as it's all static and metadata is limited.

But that's all besides the point because we're talking about simple act of launching a binary. Where "service startup/shutdown" and "life-cycle" are also just a binary being launched or killed. I thought that JACK's purpose was to launch apps with guaranteed latencies and inter-node routing, not being exclusive so less apps could be launched with guaranteed latencies and inter-node routing for less users.

[rncbc]

I thought that JACK's purpose was to launch apps...

that's your mistake: JACK does not launch any applications, never did, never will :)

also, as said, JACK is/was targeted to the pro-audio, real-time, low-latency auditoriums--it was never meant to target your regular desktop-audio use cases whatsoever.

[mxa]

@rncbc I want to break a leg for Pipewire: I mainly used Jack for the possibility of inter application routing. Now that I run Pipewire it is amazing to be able to do the same thing but not being limited to Jack enabled applications (and even video). It's also really great to avoid clock deviations, situations where with Jack one would have to use zita-bridges for resampling just work with Pipewire out of the box. I have not yet tested lowlatency, but tbh lowlatency is only one selling point of Jack and I've seen people claiming Piewire can compete there too when set up optimized for latency. There is no proper tool in Pipewire to do the patching, so the QjackCtl Graph is the most convenient tool for this even when Pipewire is running, not Jack. It would be great if QJackCtl would eventually be QPipewireControl.

[rncbc]

sorry, nope. qjackctl will stay jack-only and forever more...

PW has a complete different system model and design and to say it bluntly, its control API is currently way too complex for me to delve in :)

meanwhile you may look into yours truly spinoff, dedicated to PW alone: https://gitlab.freedesktop.org/rncbc/qpwgraph

cheers

[mxa]

meanwhile you may look into yours truly spinoff, dedicated to PW alone: https://gitlab.freedesktop.org/rncbc/qpwgraph

Holy crap Rui, that exactly what I was looking for. Awesome, thank you so much for your work!