Pipewire documentation is unclear to many users

[paper42]

• [x] it should mention that people should first try running pipewire (and pipewire-pulse) in a terminal and put it to autostart. Many people just blindly put it to their autostart scripts and go to IRC because they don't have any clues (error messages) on why it's not working.
• [ ] dbus is required, but this is not documented
• [ ] we should explicitly mention to check for "Pipewire" in the pactl info output, sometimes people still use pulseaudio, but think they use the pipewire pulse server.
• [ ] we currently use pipewire-media-session, but upstream recommends wireplumber. Until we figure out a good way to switch to wireplumber by default, I think that switching from p-m-s to wp should be documented.

[nonchip]

I've now seen various users mistakenly try to run pipewire on their "regular desktop setups" via a user service, and would like to also add that while technically nothing on the pipewire docs says to do this, I can see it being confusing for people who've just read the previous chapters including user services and (rightfully) wondered when those might come in handy.

I would therefore suggest that while the pipewire docs themselves already say to use the autostart feature of their desktop, it might be helpful to also add something along those lines to the user-services docs:

It should be noted that with this approach the per-user-services will, just like system services, always run, and should not be thought of as a replacement to the "on-login autostart" feature of your desktop environment or window manager.

especially since this line does in my opinion seem to somewhat imply a "session/seat aware behaviour":

For example, you might want to open an ssh tunnel as the current user [...]

[Vaelatern]

Oh I do this (running it as a user service). Intentionally, too. I use dwm and a rather minimal xinitrc and don't always have my x11 up when I want to play music.

[nonchip]

@Vaelatern sure thing, but that won't work for most users, at least not the way the user services are documented. because pipewire won't find a dbus session.

[Vaelatern]

Oh yeah, I've got a user-dbus as well.

#!/bin/sh

exec dbus-daemon --session --nofork --nopidfile

and

#!/bin/sh

#-- ensure XDG_Runtime_dir is set
unset XDG_RUNTIME_DIR
export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX)

pipewire-pulse
exec pipewire

Critique my setup! I'm pretty sure the pipewire-pulse call I have there is useless.

[nonchip]

@Vaelatern

Critique my setup!

one thing coming to mind is the fact you're running a dbus-daemon without a runtime dir and then ignoring that and making a new one every time the pipewire server gets started :'D

i'm honestly impressed you even get audio working with that setup, usually things like that are the reason userservices don't work with dbus :P

[Vaelatern]

Oh interesting, I think I could serve to fix that.

I'm listening to a podcast through this stack right now!

[paper42]

There are 3 components of pipewire that need to be started in some way for a working pipewire pulse server, but most setups only need to start two of them:

• pipewire itself
• pipewire-pulse
• session manager - pipewire-media-session (currently default) or wireplumber (recommended by upstream)

By default, without changing any configuration, it's enough to just start pipewire and pipewire-pulse, because pipewire.conf contains this part which means that a session manager will be started by pipewire. It's possible switch from pipewire-media-session to wireplumber here or also autostart pipewire-pulse.

context.exec = [
    #{ path = <program-name> [ args = "<arguments>" ] }
    #
    # Execute the given program with arguments.
    #
    # You can optionally start the session manager here,
    # but it is better to start it as a systemd service.
    # Run the session manager with -h for options.
    #
    { path = "/usr/bin/pipewire-media-session" args = "" }
    #
    # You can optionally start the pulseaudio-server here as well
    # but it is better to start it as a systemd service.
    # It can be interesting to start another daemon here that listens
    # on another address with the -a option (eg. -a tcp:4713).
    #
    #{ path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
]

I am confused about this part of your service:

pipewire-pulse
exec pipewire

If I am reading this right, it will execute pipewire-pulse, wait for it to finish and execute pipewire, but pipewire-pulse is a daemon which which will only finish if it's not configured properly or if pipewire was not running when it was started. This means that pipewire-pulse will fail and exec pipewire will run. The only way I can think of how this can work is if you modified pipewire.conf and uncommented the last line in context.exec - starting pipewire-pulse.

If you want to keep using services, I would suggest just using two services that have access to your user dbus session, one for pipewire, one for pipewire-pulse. You can see now why I don't think it's a good idea to suggest user services for this.

I just use the autostarting mechanism of my DE - /etc/xdg/autostart/pipewire.desktop:

[Desktop Entry]
Name=PipeWire
Comment=Start PipeWire
Icon=pipewire
Exec=pipewire
Terminal=false
Type=Application
NoDisplay=true

and /etc/xdg/autostart/pipewire-pulse.desktop

[Desktop Entry]
Name=PipeWire pulse
Comment=Start the PipeWire pulse server
Icon=pipewire-pulse
Exec=pipewire-pulse
Terminal=false
Type=Application
NoDisplay=true

This method is much simpler, I don't have to worry about anything, my DE will handle everything for me. I would like to include .desktop files like these two in the pipewire package as examples and document that they are there and that users can just link them to their /etc/xdg/autostart or ~/.config/autostart.

[paper42]

• [ ] some people come to IRC with a correct setup and no error messages in the logs, but also no sound output and it's because the device is muted and can be easily unmuted in pavucontrol. Why is this happening and why only to some people?
• [ ] pipewire prints some warnings about rtkit missing ootb, we should document what that means and what rtkit does

[ghost]

Something to add about p-m-s to wp switch, pipewire-pulse autostart & little more:

I believe the only and best way would be modifying pipewire's config in the content.exec section (last section) in which you can replace /usr/bin/pipewire-media-session with /usr/share/wireplumber.

In this section you can also uncomment the line with pipewire-pulse argument to execute it aswell,

after that you should end up with this (without comments)

context.exec = [
    { path = "/usr/bin/wireplumber" args = "" }
    { path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" }
]

There's also a guide I made which is currently on one of my github repositories > https://github.com/czarhex/dotfiles/blob/main/assets/PIPEVOID.md still needs some polishing work, since it doesn't describe well what each step does, but it's got pretty much everything needed to get pipewire going with wireplumber and pipewire-pulse without pulseaudio

[dkwo]

* [ ]  dbus is required, but this is not documented 

I thought dbus is not required, see e.g. the first few messages by developers at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2249

[ghost]

dbus isn't required. but without dbus you also don't have rtkit without rtkit you may resort to rlimits but it will impact all others applications and result in bad outcomes without placing pipewire and pipewire-pulse into very high priority you risk getting a lot of xruns

my solution: chrt -r -p 95 $$

this has the effect of

pipewire - rtprio 95

which is what they suggest in pipewire docs: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits

[nonchip]

https://github.com/czarhex/dotfiles/blob/main/PIPEVOID.md

@czarhex gz that gotta be a new deadlink speedrun ;)

[ghost]

https://github.com/czarhex/dotfiles/blob/main/PIPEVOID.md

@czarhex gz that gotta be a new deadlink speedrun ;)

oh yeah, sorry, I changed a bunch of stuff on my repo

it's now https://github.com/czarhex/dotfiles/blob/main/assets/PIPEVOID.md

[Nidrop]

Does xdg specification say anything about closing .desktop apps on logout? I just experienced some strange behavior.

My setup: KDE, SDDM and pipewire.desktop. cat /etc/pipewire/pipewire.conf.d/*:

context.exec = [ { path = "/usr/bin/wireplumber" args = "" } ]
context.exec = [ { path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" } ]

After logging out from x11 session, pipewire does not die. When I log into x11 session again, I have two pipewire stacks running. However, the wayland session works as expected, it closes its pipewire instances on logout. I thought it was sddm issue and tried lightdm. But in addition to x11, lightdm had the same broken behavior with wayland. Can anyone confirm this?

[classabbyamp]

sounds like an issue with processes started by kde not getting killed. has nothing to do with the autostart spec. maybe has something to do with KDE's autostart implementation.

[Luciogi]

process can be killed by adding logout script