[Solved?] Sound issues on MATE with pipewire and openrc

[Inisterr]

Hello. I wasn't sure where I should report it, and I didn't find any information about this issue, so I'm writing about it here.

There's a problem with sound in MATE. I cannot control volume with keyboard, so I have to set it with a sound applet. When I connect my bluetooth headphones, I can't even set volume with an applet. I have to open up mate-volume-control, click on my headphones, and then sometimes it lets me change volume in it (still no keyboard control... It may show that I change volume, but it doesn't apply. I can set it to 0 and sound is still playing).

I found a workaround, though I'm not sure how reliable this solution is. First, I had to enable pipewire and pipewire-pulse as user services, then I left gentoo-pipewire-launcher to launch on autostart with a delay.
I tried many other things, but only this method make sound control work on MATE.

I also need to mention this does not happen with only pulseaudio installed (without pipewire), and on systemd installs, where sound works without any issues. I couldn't find any errors about it in logs.

Marking this post as solved (kind of) because of the workaround. I'd prefer not to have this service mess though...

[flexibeast]

I found a workaround, though I'm not sure how reliable this solution is. First, I had to enable pipewire and pipewire-pulse as user services, then I left gentoo-pipewire-launcher to launch on autostart with a delay.
I tried many other things, but only this method make sound control work on MATE.

When using OpenRC, and choosing to use PipeWire as your sound server, then yes, `gentoo-pipewire-launcher` needs to be started somehow; refer to this section of the "PipeWIre" page on the wiki for details. (i'm not a MATE user, and don't know whether MATE makes use of the relevant autostart file.) However, in that case, you should not also be trying to run user services for `pipewire`, `pipewire-pulse` and `wireplumber`, as that will conflict with the instances of those things started by the `gentoo-pipewire-launcher` script.

More generally, as the "PipeWire" page notes:

OpenRC 0.60 introduced support for user services, and eventually PipeWire services will be provided via that functionality; however, as of 2025-11-22, gentoo-pipewire-launcher should continue to be used.

[Inisterr]

When using OpenRC, and choosing to use PipeWire as your sound server, then yes, you need to run `gentoo-pipewire-launcher` somehow; refer to this section of the "PipeWIre" page on the wiki for details. However, in that case, you should not also be trying to run user services for `pipewire`, `pipewire-pulse` and `wireplumber`, as that will conflict with the instances of those things started by the `gentoo-pipewire-launcher` script.

Yes, I know about it. However, running only gentoo-pipewire-launcher causes all these issues (it's enabled in autostart by default on MATE). It should load pipewire properly, but I think it's integration with MATE is broken, at least on my setup...?
So I tried with openrc services, knowing it might not work and gentoo-pipewire-launcher should be used instead. It also didn't fix my problem, but... Somehow leaving these services and bringing back gentoo-pipewire-launcher (I apologize for not mentioning I'm launching it with a restart parameter, so it stops previous pipewire and wireplumber processes anyway) fixes everything. I don't even know how, I had this issue for months, then I switched to systemd... Now I have another Gentoo install on openrc, the sound problem is still there unless I use this weird method that somehow solves my problem instead of breaking pipewire even further...

[flexibeast]

Okay. Well, `gentoo-pipewire-launcher` doesn't do any specific integration with specific desktop environments - here's the script contents - it should "just work". There don't seem to be any current MATE bugs mentioning the issue you're facing, so it might be something specific to your system, or it might be that others also facing the issue haven't yet reported it on the bug tracker.

It vaguely smells like some sort of race condition ....

What happens if you let the autostart do its thing, but don't start all the PipeWire-related services, then run `gentoo-pipewire-launcher restart` once the desktop environment has finished loading? Does that not have any effect?

[flexibeast]

(And if it is a race condition, it might involve PipeWire getting started before the required D-Bus session bus is available. But, one step at a time.)

[Inisterr]

What happens if you let the autostart do its thing, but don't start all the PipeWire-related services, then run `gentoo-pipewire-launcher restart` once the desktop environment has finished loading? Does that not have any effect?

Nothing changes. I still can't control volume.

[flexibeast]

Okay. i presume you're using the user service provided by the media-video/pipewire package: https://github.com/gentoo/gentoo/blob/m ... wire.initd

That service expects to find a D-Bus session bus address at ${XDG_RUNTIME_DIR}/bus.

The autostart file, https://github.com/gentoo/gentoo/blob/m ... desktop-r2, just calls `gentoo-pipewire-launcher restart`.

There are multiple potential issues here, including the fact that the above service doesn't start an instance of PipeWire with the pipewire-pulse configuration, which is a problem if MATE expects a Pulse interface for audio.

In that case, one possible scenario is:

* The `pipewire` service is sucessfully started, presumably after a D-Bus session bus becomes available (which might be a result of it being created via `need dbus`). But it doesn't start a PipeWire instance with the pipewire-pulse configuration (`pipewire -c pipewire-pulse.conf`).
* Then, running `gentoo-pipewire-launcher restart` via autostart, after a delay, occurs in the context of a D-Bus session bus now being available, and so it starts correctly, including starting a pipewire-pulse-based instance of PipeWire, in addition to the "native PipeWire API" instance, which the service hadn't done.

First and foremost, i'd like to check what's happening with the needed D-Bus session bus. So:

Remove the PipeWire-related .desktop files from the autostart sequence, don't start any PipeWire-related services, don't run `gentoo-pipewire-launcher`:

* Once your desktop is loaded up, does ${XDG_RUNTIME_DIR}/bus exist, and if so, is it non-empty?
* If it's non-empty, are its contents the same as the output of `echo $DBUS_SESSION_BUS_ADDRESS` run in a terminal on the desktop?
* If so, does then running `gentoo-pipewire-launcher restart` make things work?

(As a semi-aside, what you're experiencing might be exposing issues in what we're doing in the media-video/pipewire package, and if so, i'll try to fix those issues.)

[Inisterr]

Okay. i presume you're using the user service provided by the media-video/pipewire package: https://github.com/gentoo/gentoo/blob/m ... wire.initd

Correct. I checked it, and... I realized I somehow completely forgot about the `wireplumber` service. I temporarily enabled it along with `pipewire` and `pipewire-pulse`, and sound does work correctly without having to run gentoo-pipewire-launcher restart. I really apologize for this oversight.

Remove the PipeWire-related .desktop files from the autostart sequence, don't start any PipeWire-related services, don't run `gentoo-pipewire-launcher`:

* Once your desktop is loaded up, does ${XDG_RUNTIME_DIR}/bus exist, and if so, is it non-empty?

I disabled any pipewire services or scripts. After logging in, `${XDG_RUNTIME_DIR}/bus` does not exist. I ran gentoo-pipewire-launcher restart, it was still not present.
However, using user services, `${XDG_RUNTIME_DIR}/bus` now exists. (I can't check its contents... To be honest, I'm not sure how, using `cat` returns)

Code: Select all

/run/user/1000/bus: No such device or address

(I assume that's not how it should be done)

[flexibeast]

Correct. I checked it, and... I realized I somehow completely forgot about the `wireplumber` service. I temporarily enabled it along with `pipewire` and `pipewire-pulse`, and sound does work correctly without having to run gentoo-pipewire-launcher restart. I really apologize for this oversight.

Heh, that's okay; it's a common oversight, which is why i try to be careful to write things like "PipeWire-related" instead of just "PipeWire".

I disabled any pipewire services or scripts. After logging in, `${XDG_RUNTIME_DIR}/bus` does not exist. I ran gentoo-pipewire-launcher restart, it was still not present.

Yep, that makes sense; `gentoo-pipewire-launcher` assumes a D-Bus session bus is available, and doesn't try to start one itself if not. i'll come back to this below.

However, using user services, `${XDG_RUNTIME_DIR}/bus` now exists.

Yep, that also makes sense, as the `pipewire` service contains `need dbus` in the `depend` function, which will force the creation of a D-Bus bus.

(I can't check its contents... To be honest, I'm not sure how, using `cat` returns)

Code: Select all

/run/user/1000/bus: No such device or address

(I assume that's not how it should be done)

Hmm. Well, the primary location of a D-Bus session bus address is the environment variable DBUS_SESSION_BUS_ADDRESS; the existence of a file, and its location, is optional. (On my system, on which i use s6-rc to start a D-Bus session bus because OpenRC user services are a relatively recent thing , i store it in "${XDG_STATE_HOME}/session-bus-address", the contents of which i ensure is propagated to environments that require the value.) So it's DBUS_SESSION_BUS_ADDRESS having a non-empty value in the environment that's critical. And there are several reasonable ways of creating the session bus and populating DBUS_SESSION_BUS_ADDRESS, depending on the context: using dbus-run-session(1), using dbus-launch(1), using dbus-daemon(1) with the `--session` option (which is what i do in my s6-rc service script) ....

All that said, i'm not sure i understand what's going on in your case; on my system:

Code: Select all

$ cat /run/user/1000/bus
cat: /run/user/1000/bus: No such file or directory

More generally, thank you for your patience and willingness to get into the details on this. To me, it's identified several issues with the media-video/pipewire package that i feel should be addressed, including that `gentoo-pipewire-launcher` should probably explicitly check for the existence of a D-Bus session bus, and explicitly note if it can't find one. i'll open a bug and post the link here.

[flexibeast]

Bug 970611

[Inisterr]

Alright, I think I understand everything. Thank you so much for your help!