User:Sam/PipeWire changes


 * PipeWire needs a session manager
 * Before 0.3.49, PipeWire used (now split-out, but we don't package it) pipewire-media-session.
 * As of 0.3.49, PipeWire will use.
 * WirePlumber will take over both audio and video needs for PipeWire once setup.

Most discussions about how to move forward are currently happening in #gentoo-desktop on IRC between leio, sam, and i-garrison. Help is welcome!
 * pipewire-media-session didn't do this (why again? it's been so long! TODO)
 * pipewire parts required for alsa audio can be made optional if needed
 * this may help if there is a need to have alsa-only audio while allowing screencast via pipewire
 * in fact, upstream meson.build has 'alsa' feature with auto-detection enabled, but this is not expressed in pipewire ebuild via IUSE alsa
 * instead, pipewire ebuild unconditionally depends on alsa-lib to make 'alsa' auto-detection succeed

OpenRC

 * OpenRC users are forcefully migrated if using an XDG-compliant desktop environment because of the autostart script installed to which will run.
 * If PipeWire is pulled in as a dependency (like e.g. with GNOME, which needs it for screencasting), their audio is taken over by PW too.
 * Problem: It is not easy for OpenRC users to disable this at all!

systemd

 * The situation here is quite manual. Users are prompted to use to handle enabling/disabling PipeWire, WirePlumber, and PulseAudio's daemon. It works pretty well other than the manual aspect.
 * We don't have the same "takeover" problem as OpenRC.
 * Problem: We have no way for users to have things "just work". We can investigate systemd presets to try solve this. But it's less urgent than the OpenRC situation where there's no choice.

Solutions (or towards them...)

 * leio together with i-garrison (a Gentoo contributor and PulseAudio developer) have split the PulseAudio package into two:
 * This has helped a lot with simplifying the picture for users and making it easier for users to choose between PulseAudio and PipeWire, at least to a degree.
 * i-garrison has started working on a way to selectively enable pipewire audio parts and for users to express exactly which audio server they want, as a proof of concept: https://github.com/gentoo/gentoo/pull/25502
 * We need to figure out what this will look like in terms of USE flags, package names, documentation.
 * We need to make it easy for users to know how to choose PipeWire, PulseAudio, or JACK for their audio needs.
 * Is it required to have "no sound server" option? like in "plain alsa only" but still with screencast over pipewire
 * We should also explain somewhere that using PulseAudio via libpulse is the most common way of actually using PipeWire, given very little uses PipeWire's own APIs.
 * Problem: PipeWire (or WirePlumber?) doesn't cleanly support "disabling audio mode". If it did, we could make life a lot easier.
 * PipeWire provides loadable modules which are only used if WirePlumber configuration enables them
 * It is WirePlumber configuration which effectively enables "audio mode" by default. This is because configuration files provided by upstream and installed by wireplumber ebuild have the following entries: alsa_monitor.enabled = true and bluez_monitor.enabled=true
 * First commit in https://github.com/gentoo/gentoo/pull/25502 patches installed WirePlumber configuration to disable both alsa and bluez effectively disabling "audio mode" and second commit shows how to selectively enable either alsa or bluez or both.
 * It is WirePlumber configuration which effectively enables "audio mode" by default. This is because configuration files provided by upstream and installed by wireplumber ebuild have the following entries: alsa_monitor.enabled = true and bluez_monitor.enabled=true
 * First commit in https://github.com/gentoo/gentoo/pull/25502 patches installed WirePlumber configuration to disable both alsa and bluez effectively disabling "audio mode" and second commit shows how to selectively enable either alsa or bluez or both.

Proposal 1: Add pipewire IUSE sound-server
This proposal is intended to solve a runtime conflict between pipewire with audio function enabled and pulseaudio daemon over alsa-lib and bluetooth resources.

Proposal status: Implemented.

Originally  was introduced to implement screen capture via USE   for desktop environments. Note there are already 9 users of USE screencast so maybe consider making that a global USE flag. Further development added sound server function to pipewire, with ability to substitute sound server implementation for pulseaudio clients and also Jack clients. Using pipewire in place of pulseaudio daemon or jack daemon is popular with users.

Unfortunately existing implementation of pipewire sound server function in Gentoo restricts possible use cases. Since pipewire sound server function is unconditionally enabled this introduces a conflict at least with pulseaudio daemon (with respect to accessing alsa devices and bluetooth audio devices) which is also usually found installed by default. A user willing to install pipewire package to satisfy their desktop  needs is forced to switch to pipewire sound server too, which is not how this should work. Instead, a user should be given a choice.

To support the choice, add IUSE  to. Scope of pipewire sound server function controlled by IUSE  would be all audio devices, i.e. currently alsa-lib devices and bluetooth audio devices. To resolve a conflict over alsa-lib and bluetooth audio devices It now makes sense to explicitly refer to sound server function of  with proper blocker in   RDEPEND="!media-video/pipewire[sound-server(+)]" Whether IUSE  is enabled by default is out of scope of this discussion.

Use case: Use pipewire for video processing only.
A user would not enable USE  on.

Screen capture function via USE  for desktop environments is not affected.

A user is free to use ALSA audio or install any other sound server.

Use case: Force pipewire for both video and audio.
A user would enable USE  on.

Screen capture function via USE  for desktop environments is not affected.

While re-emerging pipewire package a blocker would be resolved to uninstall  package.

Use case: existing pulseaudio user installs pipewire for screen capture.
Depending on user choice wrt USE  for pipewire package, either   or   would be emerged.

Screen capture function via USE  for desktop environments is not affected.

Use case: USE sound-server is not set, pipewire audio for user A and pulseaudio for user B
System administrator would not enable USE  on   and install both pipewire and pulseaudio packages.

User A would alter their private configurations to disable pulseaudio daemon and enable pipewire sound server function.

User B satisfied by default.

Proposal 2: Add new package virtual/sound-server
This proposal is intended to solve a problem where e.g. a desktop environment ebuild needs to make sure there is a sound server installed.

Proposal status: Discarded; not useful even for transitional purposes (pulseaudio metapackage and PDEPEND in libpulse works)

New package virtual/sound-server will RDEPEND on either media-video/pipewire[sound-server] or media-sound/pulseaudio-daemon.

A problem with this approach is that it is not known whether installing any sound server will help providing desktop audio function.

Proposal 3: make media-sound/libpulse PDEPEND on pipewire[sound-server] or pulseaudio-daemon
This proposal is intended to solve a problem where an application is using libpulse client libraries but there is no sound server installed.

Proposal status: Implemented.

This looks better than proposal 2 alone: installing a sound server would likely allow an application using libpulse to have working audio. While this dependency can be implemented via "PDEPEND=virtual/sound-server" there is no real need for new virtual package.

Bugs to chew on and read

 * (includes details of the pipewire-media-session -> wireplumber issues)