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

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

Code: Select all

pulse.properties = {
    # the addresses this server listens on
    server.address = [
        "unix:native"
        #"unix:/tmp/something"              # absolute paths may be used
        "tcp:127.0.0.1:4713"                 # local server only
        #"tcp:4713"                         # IPv4 and IPv6 on all addresses
        #"tcp:[::]:9999"                    # IPv6 on all addresses
        #"tcp:127.0.0.1:8888"               # IPv4 on a single address
        #
        #{ address = "tcp:4713"             # address
        #  max-clients = 64                 # maximum number of clients
        #  listen-backlog = 32              # backlog in the server listen queue
        #  client.access = "restricted"     # permissions for clients
        #}
    ]
    #pulse.min.req          = 128/48000     # 2.7ms
    #pulse.default.req      = 960/48000     # 20 milliseconds
    #pulse.min.frag         = 128/48000     # 2.7ms
    #pulse.default.frag     = 96000/48000   # 2 seconds
    #pulse.default.tlength  = 96000/48000   # 2 seconds
    #pulse.min.quantum      = 128/48000     # 2.7ms
    #pulse.idle.timeout     = 0             # don't pause after underruns
    #pulse.default.format   = F32
    #pulse.default.position = [ FL FR ]
    # These overrides are only applied when running in a vm.
    vm.overrides = {
        pulse.min.quantum = 1024/48000      # 22ms
    }
}

I then put the server info in my web-browsing user's .bash_profile:

Code: Select all

PULSE_SERVER=tcp:127.0.0.1:4713
export PULSE_SERVER

That seems to do the trick (after rebooting to restart the pipewire server). It mixes the audio from the primary user (the desktop user) and the web-browsing user (ie firefox running from a terminal as a different web-browsing user.) Running "pactl info" gives me the same info with both users (other than Client Index).
I use OpenRC not systemd. However, the Gentoo Wiki https://wiki.gentoo.org/wiki/PipeWire#R ... irePlumber calls out a new pipewire-gentoo-launcher script for restarting the server. I haven't had a need to use that yet though. With KDE my volume controls also seem to work correctly.

[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: Select all

   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]

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.

For me the main reasons are google-chrome and discord.

Is there any advantage to having the main user export PULSE_SERVER?

Consistency: I just put the setup in my global profile.

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)

For me, this is the case, but especially google-chrome and discord is something I want to run with reduced permissions.

What I have written about stopping after 10 minutes: Probably something strange happened - some sort of crash without the daemon dying. Now it works since many hours.

[ormorph]

Run as user:

Code: Select all

$ gentoo-pipewire-launcher
$ chmod 777 /var/run/user/$UID/pipewire-0
$ echo $UID
1000

Under a different user, create or edit the file ~/.bash_profile. Add lines:

Code: Select all

if ! [[ -f "/run/user/$UID/pipewire-0" ]] ; then
        ln -sf "/run/user/1000/pipewire-0" "/run/user/$UID/pipewire-0"
fi

As a result, sound and alsamixer will also work normally under another user.
To prevent bluetooth from crashing when switching tty session, add a line to /etc/wireplumber/bluetooth.lua.d/89-gentoo-sound-server-enable-bluez-monitor.lua:

Code: Select all

bluez_monitor.properties["with-logind"] = false

This method works for all users.

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

Funny how sound configuration did not become easier in 20+ years.

Everything is in the UNIX way.
In single-user mode, everything works fine, but for multi-user mode, you need to make the socket of the running pipewire process accessible to all users, then it doesn’t matter which output is used by alsa or pulseaudio. Also, if you launch pipewire from the console, you need to use dbus-launch for this, otherwise you will not be able to connect via bluetooth.

Code: Select all

$ dbus-launch gentoo-pipewire-launcher &

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

Code: Select all

# rc-update add pipewire
# reboot

The only thing is that if you need the bluetooth sound not to drop, you need to add a line to the file /etc/wireplumber/bluetooth.lua.d/89-gentoo-sound-server-enable-bluez-monitor.lua:

Code: Select all

bluez_monitor.properties["with-logind"] = false

Now all this is done quite simply, you can remake this ebuild for yourself.
Also, the file /etc/xdg/autostart/pipewire.desktop needs to be deleted.

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

[ormorph]

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.

This is up to the Gentoo developers to decide. You can write to them in the bugzilla and show them this example, and they should already draw conclusions based on this. I did this for myself, since I don’t really like the solution of autoloading the .desktop file. On the TDE desktop, system sounds run through the artsd sound server, so running pipewire as a system daemon is preferable. And of course, after adding this demon, now I like the sound work much more, since everything has become much more convenient.

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

[ormorph]

Updated to version media-video/pipewire-1.0.7, bluetooth sound stopped working. To solve the problem, you need to add a line to the file /etc/wireplumber/wireplumber.conf.d/gentoo-sound-server-enable-audio-bluetooth.conf: monitor.bluez.seat-monitoring = disabled
Example:

Code: Select all

wireplumber.profiles = {
  main = {
    hardware.audio = required
    hardware.bluetooth = required
    monitor.bluez.seat-monitoring = disabled
  }
}