Talk:PipeWire

Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

gentoo-pipewire-launcher

Talk status

This discussion is done.

This page currently makes a number of references to gentoo-pipewire-launcher, but as of today (2022-04-10), the media-video/pipewire build seems to not install such a file. However, it does contain /usr/libexec/pipewire-launcher; should references to the former be replaced by references to the latter? -- Flexibeast (talk)

What version are you talking about? I recall that the stable version 0.3.36 won't have that yet, and since this is very experimental at this stage, this wiki page refers to mostly unstable builds.

Gabrielg (talk) 08:05, 10 April 2022 (UTC)

Oh! Sorry, yes, 0.3.36. Thanks, all noted. -- Flexibeast (talk)

Necessity of screencast USE flag

Talk status

This discussion is done.

A recent discussion on r/Gentoo indicates how the current text:

The use of PipeWire by applications natively is governed by the USE=screencast USE flag, on each package that has optional PipeWire support.

is ambiguous. Is the screencast flag only required if one needs to do screencasting, or is it more generally required for applications to use PipeWire natively?

-- Flexibeast (talk)

Afaik, it is only for the screencasting. For sound-server, applications are still using pulseaudio USE flag and pipewire will act as pulseaudio server if you choose to replace pulseaudio with pipewire (by setting sound-server on pipewire and -daemon on pulseaudio). -- Ultratensai (talk)

In the absence of any comments disagreeing with the preceding, i'm marking this discussion as closed. -- Flexibeast (talk) 01:16, 22 April 2023 (UTC)

USE flags

Talk status

This discussion is done.

[Moved from User talk:Flexibeast; regarding revision of 23:09, 21 April 2023 by Flexibeast] It is kinda redundant, but I added that so if someone just goes to the "replace pulse" portion, they can follow those steps, it's easy to miss the portion above, jumping straight to the instructions. -- User:Zen_desu

Yes, i understood that you'd interpreted the first and second paragraphs as two distinct sets of instructions - the phrasing was ambiguous, so that was certainly a reasonable interpretation! However, in order to avoid needless repetition of information, wiki pages typically provide instructions applicable to all cases, before then addressing specific cases. So i not only removed your text, but also modified the text of the second sentence to say "Then, if ..." to try to link the two paragraphs, and make it clear that the instruction of the first sentence should have already been completed at this point. -- Flexibeast (talk) 01:07, 22 April 2023 (UTC)

nohup not working with gentoo-pipewire-launcher

Talk status

This discussion is done as of 2023-09-07.

There seems to be something about wireplumber that is counteracting nohup, and thus after running nohup gentoo-pipewire-launcher restart & and subsequently closing the terminal, wireplumber exits. I have tried modifying the script to omit the exec and add & to background wireplumber, but it still exits after the terminal closes. For now I've started using Bash's disown instead, which seems to work. I'm on pipewire 0.3.75-r2. --GNUru (talk) 04:39, 5 September 2023 (UTC)

Thanks for reporting this. i'm wondering whether the issue is that WP is crashing due to file descriptors getting closed when the terminal is closed. As a test, does WP still shut down down if you instead do something like nohup gentoo-pipewire-launcher </dev/null >~/g-p-l.log 2>&1 &? -- Flexibeast (talk) 09:43, 7 September 2023 (UTC)

gentoo-pipewire-launcher already redirects stdout/err when running wireplumber. I tried adding </dev/null but it made no difference. I also just tried running nohup gentoo-pipewire-launcher </dev/null >~/g-p-l.log 2>&1 & and that also made no difference. I suspect wireplumber is modifying its signal mask. If I run nohup gentoo-pipewire-launcher restart &, then before closing the terminal I can see that the 2 pipewire processes have SIGHUP ignored while wireplumber does not:

$ grep SigIgn $(for p in $(pidof pipewire); do echo /proc/$p/status; done)

/proc/32748/status:SigIgn: 0000000000000007

/proc/32746/status:SigIgn: 0000000000000007

$ grep -H SigIgn /proc/$(pidof wireplumber)/status

/proc/32732/status:SigIgn: 0000000000001000

SIGHUP is signal 1 (as seen in kill -l), so if it was ignored then we'd have the 1 bit enabled. It's enabled for the 2 pipewire processes, but not for wireplumber.

I submitted an issue upstream, https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/505, and I've also updated the main page's "Restarting_PipeWire_and_WirePlumber" section. --GNUru (talk) 14:40, 7 September 2023 (UTC)

Thanks for all your effort in resolving this, I've marked this as closed for now as the wiki is solved.

Immolo (talk) 14:47, 7 September 2023 (UTC)

audio group

Talk status

This discussion is still ongoing.

Special:Diff/1294717 by Stdnt changes the text to mention audio like a recommendation, but the text below it says to only do this if you're relying on it for ACLs, as otherwise it'll break fast user switching. I think we should probably keep it as it was. Thoughts? --Sam (talk) 20:38, 26 April 2024 (UTC)

Hmm .... i wonder if what might be best is move the discussion about fast user switching and ACLs to the start of the section, and additionally, give a specific example of a case where access control is needed/used, to help clarify what is meant by it? (i don't know one myself.) i guess it might be a thing of "If you don't know what it is, you don't need it", but are there configurations where someone might be making use of access control without being actively aware of it? At any rate, i'm thinking of the opening being something like:

PipeWire's default configuration tries to use realtime scheduling to increase audio thread priorities. Users should be in the pipewire group. For the best fast user switching experience, users should not be in the audio group unless the system is configured to utilise that group for device access control / ACLs - for example, [example]. In the latter case, add users to the audio group:

[command line]

and then remove the relevant text later in the section.

-- Flexibeast (talk) 02:32, 27 April 2024 (UTC)

Whoops, I undid it without checking the talk page first. As much as I hate reverting edits, I think it was the best option here.

I'm not familiar with ACLs, so I unfortunately can't provide examples.

— Waldo Lemmer 03:57, 27 April 2024 (UTC)

i can certainly confirm that PipeWire works for me without me needing to be in the audio group.

-- Flexibeast (talk) 06:32, 27 April 2024 (UTC)

And I can certainly confirm that PipeWire does NOT work for me without having to be in the audio group. (the PipeWire configuration, sway as DE). --Lars Hint (talk) 07:15, 27 April 2024 (UTC)

It's supposed to go through Wayland for audio permissions. I don't understand why it wouldn't work for you.

— Waldo Lemmer 08:33, 27 April 2024 (UTC)

Ah, interesting! i'm on Wayland myself (Wayfire) - i used to use Sway, but haven't tried it recently in this regard. One thing that occurs to me: i'm running elogind (i.e. elogind-daemon). Lars, are you running systemd / elogind / seatd?

-- Flexibeast (talk) 09:21, 27 April 2024 (UTC)

seatd --Lars Hint (talk) 09:56, 27 April 2024 (UTC)

I just tested the Gentoo live image (PipeWire installation script), the configuration worked fine without the audio group in KDE. --Lars Hint (talk) 10:12, 27 April 2024 (UTC)

pipewire-pulse.service

Talk status

This discussion is done.

Section systemd says to enable the correct services as follows:

user $systemctl --user enable --now pipewire.socket pipewire-pulse.socket wireplumber.service pipewire-pulse.service

But that command includes both pipewire-pulse.socket and pipewire-pulse.service. The socket should automatically start the service when needed, so pipewire-pulse.service should not need to be enabled. I can confirm this — pipewire-pulse.service is disabled on my system, but is running and I always have sound (Plasma on Wayland).

The next paragraph says this:

Socket activation means the service will only be started when required, which is usually sufficient. However, the user service can be always started when the user logs in by replacing pipewire.socket with pipewire.service:

user $systemctl --user enable --now pipewire.service

Maybe pipewire-pulse.service should be added to that paragraph and command instead?

— Waldo Lemmer 03:23, 1 May 2024 (UTC)

Closing. See Special:Diff/1296432.

— Waldo Lemmer 09:56, 2 May 2024 (UTC)