Talk:PipeWire

From Gentoo Wiki
Jump to:navigation Jump to:search
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)