[Pipewire]Output sound from app running under different user

[Dr. Banana]

The scheme is simple: running a Xorg/Wayland session as a 'main' user and launching something like firefox as a different user with sudo. Using pipewire, what is the proper way to make sure that firefox will output sound. I've tried this and the closest I could get was by uncommenting the tcp:4713 line under server.address[] in pulse.properties{} in /etc/pipewire/pipewire-pulse.conf, and exporting the PIPEWIRE_PULSE variable for both users. This way I was able to output sound, but the problem was this didn't allow me to change the volume, rather it got stuck. Moreover under this setup it's impossible to recover pipewire if it crashes (other than rebooting). So I was wondering if anybody here had a way to get this working. I use systemd by the way.
_________________
Haters gonna hate,
Potatoes gonna potate.

[radio_flyer]

That's essentially what I do. I run firefox from a KDE konsole after I su to my locked-down web-browsing user.

I added my primary desktop user and my web user to the audio and pipewire groups. I added "-daemon" to media-sound/pulseaudio and enabled the TCP server in /etc/pipewire/pipewire-pulse.conf:

[mv]

@radio_flyer:

Thank you very much for finding a great solution for the problem. Just a few remarks:

1. It seems that it is not necessary for any user to be in the pipewire group. What fails for you if you are not?
2. It seems that also the main users can export PULSE_SERVER=tcp:127:0.0.1:4713
3. On my system (pipewire-0.3.70-r2 wireplumber-0.4.14), starting up with

   Code:

   export DISABLE_RTKIT=1 PULSE_SERVER=tcp:127.0.0.1:4713 pipewire & pipewire -c pipewire-pulse.conf & sleep 1 exec wireplumber

   it seems that I should better not override pipewire.conf but instead pipewire-pulse.conf. Moreover, unless I want to modify and/or copy the whole file /usr/share/pipewire/pipewire.conf for your snippet, I should better put the snippet you posted into an override directory, for instance into the file /etc/pipewire/pipewire-pulse.conf.d/pipewire-pulse.conf. Note that none of the parent directories of this file (except /etc) existed on my system, originally.

[mv]

Hmm, it seems that after a whlie I have to kill the pipewire processes and have to run my startup script again.

But this "while" is quitge long (10 minutes or longer); is it possible to extend this period to infinity?

Note: There is also another timeout which I do not want to extend, namely the "usual" time pipewire reserves the sound device; this is only about 10 seconds. (By the latter I mean: I use neither any pulse nor pipewire plugins for alsa; then usually, when running mplayer -ao pulse ..., I cannot run mplayer -ao alsa ... - and cannot do so for a few seconds after the first mplayer stopped - due to "Device or Resource busy).

[radio_flyer]

I'm still playing with this pipewire setup as well. Until now I've been using ALSA just fine, but given the latest news it appears we're all going to have to find peace with pipewire sooner or later, particularly when running firefox.

I'm not sure any user has to be in the pipewire group. I did that originally when I was trying the '/tmp/pipewire-server' file pipe multi-user method I found online, with the owner of the file being the main desktop login user and the group set to 'pipewire'. That, however, was a complete bust. I never could get anything other than "Connection failed: connection refused" or something like that from any other user. The TCP server approach is the only one I've found so far that sorta works.

I originally had no '/etc/pipewire' config directory as well. I copied over only /usr/share/pipewire/pipewire-pulse.conf so I could modify the 'pulse.properties' config block to try to get a pulse-audio style server running and make firefox happy. I believe your solution of creating /etc/pipewire/pipewire-pulse.conf.d/some-snippet.conf--where 'some-snippet.conf' is only the pulse.properties block--is the correct approach given how rapidly pipewire evolves its configuration settings. The less user-overridden configuration, the better. I haven't done that yet because I'm still playing with the setup trying to get it solid (if that's even possible currently).

At the moment I have full success with my setup about half the time. My main desktop user has no problem running audio. When I run a konsole and su to the other user, half the time 'pactl info' reports the server, and half the time it can't connect. I then have to run 'gentoo-pipewire-launcher restart &' as the main user before the konsole user can connect. A race on KDE startup? Anyway, so far it seems relatively stable after I've reset the server. I haven't run into your timeout issue (yet).

Is there any advantage to having the main user export PULSE_SERVER? On my system pipewire seems to mix the audio from the main user and konsole user just fine, even though the main user is "going direct".

The biggest problem I'm having getting pipewire set up is that all of the documentation seems to be written with the use case of one and only one user having full control of the computer at all times (ie the Microsoft way, not the UNIX way), and there has been so much evolution in the configurations that most of the online documentation is completely worthless even if I find something that seems pertinent.

[mv]

[ormorph]

Run as user:

[dmpogo]

Funny how sound configuration did not become easier in 20+ years. This discussion reminds me of similar circa 2001, on the basis of OSS back then.

[ormorph]

[ormorph]

I wrote an ebuild to run the pipewire daemon. The daemon runs under the pipewire user, which is created when the acct-user/pipewire package is installed. Using all of the above methods, including creating the PULSE_SERVER variable, you can achieve stable operation with different users. This ebuild needs to be installed in the local overlay. Anyone who needs it can remake it (improve it) for themselves.

[ormorph]

Added a new version of the pipewiredaemon ebuild, now no changes are needed in the user’s home files.

[szatox]

ormorph, I wonder if it could be integrated into ebuilds already existing in the main repo.
media-video/pipewire[/code] already has "system-service" use flag, which I think enables global configuration, but it is currently only allowed with systemd. Would be great to have it init-agnostic.
_________________
Make Computing Fun Again

[ormorph]

[ormorph]

Hmm, I looked at how it works in systemd, only single-user mode works there too. What I posted is the only working version of the multi-user pipewire mode. For systemd you can do the same thing, but you will need to write your own unit. I use openrc, those who use systemd can use my work with pipewire and write it for themselves.

[ormorph]

Slightly reworked the ebuild and pipewiredaemon scripts. Now it is tied not to the tcp address but to the unix socket. When using a tcp address, the pulseaudio information was displayed, but it was not possible to change the audio settings through the pulseaudio tools. Now it all works.