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.

[flexibeast]

that's the first time I've ever seen an audio subsystem doing video capture. Seriously... Why?

Quoting Wikipedia:

In 2015, Taymans started work on PipeWire. It was based on ideas from several existing projects, including one called PulseVideo by William Manley. According to Red Hat's Christian Schaller, it drew many of its ideas from an early PulseVideo prototype by Manley and builds upon some of the code that was merged into GStreamer due to that effort. A goal of the project was to improve handling of video on Linux in the same way that PulseAudio improved handling of audio.

Although a separate project from PulseAudio, Taymans initially considered using the name "PulseVideo" for the new project. By June 2015, the name "Pinos" was being used, after the city Pinos de Alhaurin in Spain, where Taymans used to live.

Initially, Pinos only handled video streams. By early 2017, Taymans had started working on integrating audio streams. Taymans wanted to support both consumer and professional audio use cases, and consulted Paul Davis (Jack developer) and Robin Gareus (Ardour developer) for advice on implementation for professional audio. At this time, the name PipeWire was adopted for the project.

[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

Code: Select all

 $ pw-link -l
eq15_out:output_FL
  |-> alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FL
eq15_out:output_FR
  |-> alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FR
alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FL
  |<- eq15_out:output_FL
alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FR
  |<- eq15_out:output_FR

standard connection, equalizer to alsa

Code: Select all

$ pw-link -l
eq15_in:playback_FL
  |<- DeaDBeeF Music Player:output_FL
eq15_in:playback_FR
  |<- DeaDBeeF Music Player:output_FR
eq15_out:output_FL
  |-> alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FL
eq15_out:output_FR
  |-> alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FR
alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FL
  |<- eq15_out:output_FL
alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FR
  |<- eq15_out:output_FR
DeaDBeeF Music Player:output_FL
  |-> eq15_in:playback_FL
DeaDBeeF Music Player:output_FR
  |-> eq15_in:playback_FR

If I wanted to add say a second alsa output you would do something like (changing output name as appropiate)

Code: Select all

pw-link eq15_out:output_FL alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FL
pw-link eq15_out:output_FR alsa_output.pci-0000_0d_00.4.analog-stereo:playback_FR

and the pw-link -l would show an extra output (in this case a second output for eq15_out* line, left and right channel)

Part of the reason for handling channels separately is it allows one to do things with multi-channel, or something like swapping left and right.

Edit to add: In my case I use it like this, when I plug in my bluetooth headphones, it automatically shuts off speakers.
Sometimes I want to leave the headphones on, but want to also have the stereo speakers on so I would use the above to add speakers.
In this case the speakers aren't a permanent connection, if I stop deadbeef then those links I've added would disappear when deadbeef is restarted.

There's probably a way to script the connections through pipewire/wireplumber and make them permanent,
but I haven't delved far enough into to the docs to figure it out.

[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.

[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.

I don't run multi-user so I've never set it up, and it's not the typical usage

The only reason it's not typical is because programmers like to invent technical solutions to social problems. And I'll stop here, before I write a book about my reasons
In case of pure alsa anyone in audio group can open dmix and start driving the speakers. It is a good thing.
I want the same behavior, just with added benefit of a virtual patch bay. Restricting access to the virtual patch bay makes sense, but there is no need to prevent programs from sending or receiving signals from the sound system.

[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.

[szatox]

Have you tried running two pipewires at the same time (one per user), using a common config file.

I managed to get sound after a full login, but not when changing a user for application via su.
Only one source can be active at any time though, since I don't have a hardware mixer. Launched 2 mplayers this way... The second one simply froze.

Everything devolves to using alsa underneath it, as far as I can tell.

Almost... AFAIK it talks directly to hardware, which makes perfect sense, but also creates a conflict on any audio device without a hardware mixer. I don't know if it's possible to point a sound server to dmix instead, and if it was, how to control the output afterwards. Like that BT headphones you mentioned. What if I want to ring on speakers and then talk via a headset? It's not a particularly weird scenario.

Note: I run a single user system, so I haven't tried it or had the need for it.

So do I, but running everything on your user is not very different to running everything as root.
I want to drop privileges granted to certain applications and e.g. keep them out of my $HOME. Actually, I do already do that with some applications, and I'm looking for a way to make it more convenient and usable.
Does keeping a web browser out of my HOME make sense? I'd like to still let it access audio though.
How 'bout receiving notifications while mpd is playing music in the background?

Well... No rush. I don't actually _need_ it, if I can make it work, that's great, and if I can't, I'll shrug it off and do something else instead.

[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 ... wikis/home

[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.

Code: Select all

 $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 0: ALC257 Analog [ALC257 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [FUNAI TV]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Code: Select all

 $ pw-link -o
alsa_output.pci-0000_00_1f.3.analog-stereo:playback_FL
alsa_output.pci-0000_00_1f.3.analog-stereo:playback_FR
alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo:playback_FL
alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo:playback_FR

This laptop only has 1 HDMI port exposed, AFAIR the others come alive when combined with a USB-C dock. I have one with a HDMI and 2 DP ports.

[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

[szatox]

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

USE="X bluetooth dbus extra ffmpeg jack-sdk modemmanager readline sound-server ssl v4l zeroconf -doc -echo-cancel -flatpak -gsettings -gstreamer -ieee1394 -jack-client -liblc3 -lv2 -man -pipewire-alsa -roc (-selinux) (-system-service) -systemd -test"

I'm on default config right now.

Code: Select all

Audio
 ├─ Devices:
 │      33. ThinkPad USB-C Dock Gen2 USB Audio  [alsa] # card 2
 │      49. Wbudowany dźwięk                  [alsa] # card 0; builtin audio
 │      62. USB Audio Device                    [alsa] # card 1; 2$ dongle
 │  
 ├─ Sinks:
 │  *   55. Wbudowany dźwięk Analogowe stereo [vol: 0.38]
 │      67. ThinkPad USB-C Dock Gen2 USB Audio Analogowe stereo [vol: 0.40]
 │      83. USB Audio Device Analogowe stereo   [vol: 0.40]
 │  

Alsa does see HDMI outputs, but pipewire only reports access to analogue part AKA builtin speakers/headset jack.

[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)

Code: Select all

.config/pipewire/pipewire.conf.d/sink-eq15.conf
.config/pipewire/pipewire.conf
.config/wireplumber/main.lua.d/50-default-access-config.lua
.config/wireplumber/main.lua.d/40-device-defaults.lua
.config/wireplumber/main.lua.d/90-enable-all.lua
.config/wireplumber/main.lua.d/50-alsa-config.lua
.config/wireplumber/bluetooth.lua.d/50-bluez-config.lua
.config/wireplumber/wireplumber.conf

I consider pipewire.conf and wireplumber.conf as needed,

When you start pipewire/wireplumber are you directing the somewhere with the -c <config> flag or just using whatever it finds without flags?
In other words, pipewire -c /etc/pipewire/somefile & or just pipewire &

[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"

In other words, pipewire -c /etc/pipewire/somefile & or just pipewire &

gentoo-pipewire-launcher &
Which sends logs straight to /dev/null by default. Not that there was anything interesting after I made a custom config for this one. I'll get back to wireplumber's complaints after I'm done with profiles.

[Anon-E-moose]

You might try setting alsa to ucm instead of acp

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

Code: Select all

    apply_properties = {
      -- Use ALSA-Card-Profile devices. They use UCM or the profile
      -- configuration to configure the device and mixer settings.
      ["api.alsa.use-acp"] = true,

      -- Use UCM instead of profile when available. Can be
      -- disabled to skip trying to use the UCM profile.
      --["api.alsa.use-ucm"] = true,

      -- Don't use the hardware mixer for volume control. It
      -- will only use software volume. The mixer is still used
      -- to mute unused paths based on the selected port.
      --["api.alsa.soft-mixer"] = false,

The above is acp set true, ucm is commented out (not sure what default is), try turning off acp, ie set to false rather than comment out

[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

[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.