Playing with pipewire; how do I connect apps automagically?

[szatox]

I finally decided to give pipewire a shot. Oh boy, that's the first time I've ever seen an audio subsystem doing video capture. Seriously... Why?

Anyway. I got to the point where jack-aware applications talk to it directly, and alsa-only applications talk to it via pipewire-alsa. So far so good:
Web browser OK
Audacity OK
OBS OK
Direwolf OK
js8call OK

Moving on to the tricky tricks:
Applications don't like to keep their ports open. Sometimes they appear in the chart only for a few seconds, which is way too short for me to manually connect them with virtual wires, yet I want to feed output of one of them into another.
Need some sort of automation, preferably via internal triggers. Pipewire looks like something that is scriptable, so I should be able to get it done pretty easily. Question is: where and how do I start?

[CaptainBlood]

The only one I'm aware of is media-sound/qpwgraph

It doesn't act in daemon mode and needs gui to be started for patchbay rules to be applied.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

[flexibeast]

[Anon-E-moose]

It kind of makes sense for pipewire to handle audio as well as video, they're both in the multi-media arena.

pw-link allows one to script connections, (cmd line non-graphic but does work)

pw-top will show current connections (similar to top but shows pipewire components)

pw-link -i and -o (input and output respectively) or pw-link -l (to show links)

example

[szatox]

pw-link surely looks interesting, it can even run in monitor mode and notify some other program about ports and links being created and destroyed.
I also found jack.rules section in /usr/share/pipewire/jack.conf. Pipewire does not install /etc/pipewire by default, it seems we're supposed to copy and modify the example files manually when we need to override the defaults. Gotta find some reference guide for available actions though.

Another thing, any idea how can I allow multiple users to share the sound subsystem? Setting up tcp connection between several instances of pipewire is unnecessarily complex and messy; there seems to be some way to set a system-wide server instead, but it clearly is not a popular option.
My audio device does not have hardware mixer, so multiple instances writing to it directly is not an option.

[Anon-E-moose]

I don't run multi-user so I've never set it up, and it's not the typical usage. But there are some that have succeeded with it (to some degree)
Maybe hints here https://bbs.archlinux.org/viewtopic.php?id=265878 it assumes using pulse-audio/pipewire is being used IIRC

The references are ... sadly ... lacking, I've looked all over the place and some things I understand only after having tried them.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[szatox]

Yeah, I saw this topic on arch forums.
Well, when I read about pipewire, I expected a single sound server equipped with software mixer and multiclient interface talking jack, pa and alsa protocols. Now, trying to make it do different things, it feels like the protocols are actually distinct (though interconnected) cores rather than just interfaces.
E.g. going that suggested TCP route I'd basically have to use pulseaudio mode to bridge the gap between jack application on one user and alsa on another.

[Anon-E-moose]

Have you tried running two pipewires at the same time (one per user), using a common config file.
Everything devolves to using alsa underneath it, as far as I can tell.

Note: I run a single user system, so I haven't tried it or had the need for it.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[szatox]

[Anon-E-moose]

You might look at the files under /usr/share/pipewire/filter-chain as well as the pipewire wiki

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[szatox]

Uhm... What should I use filter-chain for?


In the mean time, some other things I'm testing is routing sound to different sound devices; enabling CONFIG_SND_USB_AUDIO in kernel gave me access to both, a 2$ usb audio device I bought for RPi, and the headset jack in my USB dock. I can also drive multiple outputs at the same time with a single input signal. Nice.

Any idea what do I need to send audio over HDMI? I even wired it to a TV just to see if autodetect is hiding audio sinks known to be dead, but no new ports appeared.

[Anon-E-moose]

filter chain is just some things that can be done using either builtin function or ladspa plugins and ways to combine/split streams
I use the builtin equalizer stuff

Not sure why pipewire isn't seeing the hdmi port, it definitely shows to alsa.

what are your pipewire use flags? and paste your pipewire.conf (if you're not using the system default)

also post the output of "wpctl status" at least the device section
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[szatox]

I see. Well, filters might come in handy later, but I'm not there yet.

[Anon-E-moose]

It could be because the pipewire-alsa use flag isn't set. I know the description says something about pulse, but it might be needed.

If not that, then a configuration detail in either pipewire or wireplumber configs.

I recommend setting both system configs for pipewire and wireplumber.

I have these (local overrides global)

[szatox]

Pipewire-alsa didn't help However, I found a mention of profiles in PW's FAQ. Enabling "pro" profile for a device is supposed to (among changing other settings) enable all subdevices and channels instead of making things "easy", so this is something to investigate.
Well, having only 1 output out instead of 4 definitely makes thing easier... If you happen to want the default that's been chosen for you. Anyway, right now it's a +1 for "a configuration detail"

[Anon-E-moose]

You might try setting alsa to ucm instead of acp

/etc/wireplumber/main.lua.d/50-alsa-config.lua

[szatox]

Good call, setting ["api.alsa.use-acp"] = false exposed 3 HDMI devices. And I actually got the sound out of TV speakers.
Going back to an earlier point now: setting it up as a system-wide service rather than user-specific instances competing for hardware access.

Anyway, thanks for help so far, finding all the information just by myself would have taken much more time

[Anon-E-moose]

do you have multiple users, or are you just using multiple accounts?

Edit to add: there is an option for system wide service (not recommended) using systemd,
you could probably model something after the system level service files, if not using systemd.

ETA2: it looks like all the system level stuff does is create a couple of sockets, one of 3 env vars is used to find them.
But you almost need to run pipewire/wireplumber per user, because it uses a dbus session.
If everyone is in the audio group (default) then there shouldn't be a problem
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland

[szatox]

I'm using multiple accounts, but even with multiple users (e.g. a family computer) I'd still want it to work the same way.
Sound interface is a very particular service, with unique use patterns; there is no point in protecting it the same way we would some internet-facing stuff. I can actually expect the humans around to behave (I know, trusting your users is a radical idea), so I want something suitable for a cooperative environment.
It still makes sense to guard against untrusted applications snooping on streams not intended for them, so restricting access to the patch bay would be nice to have, but given the choice between security and usability, I'm taking usability.

Do you have any leads regarding those system-level things? I found a CFLAG which should enable system-wide mode, but i don't see changes I expected from enabling it. Notably service files still don't exist on my system.
BTW, the pipewire-alsa USE flag adds a new volume knob (and breaks volume up/down hooks triggered by acpid). I haven't decided yet whether the convenience of having a single volume knob for all outputs is worth the inconvenience of adding a multiplicative knob to all outputs.

> But you almost need to run pipewire/wireplumber per user, because it uses a dbus session.
Yeah, it does make things messy. I wonder if there is a workaround for that.
I like that wireplumber is scriptable with LUA though, it should make injecting my own policy reasonably easy once I get to that part. This one thing might actually be a somewhat niche use case

> If everyone is in the audio group (default) then there shouldn't be a problem
There shouldn't be a problem with getting audio out to the speakers through dmix, though it adds extra latency and CPU time. Users running their own, private audio servers still gets in the way of piping sound from one application to another, right?

I think it's about time to hit their IRC or something and as some questions right at the origin of this little adventure.