User:Sam/PipeWire changes

From Gentoo Wiki
Jump to:navigation Jump to:search
  • 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 media-video/wireplumber.
  • WirePlumber will take over both audio and video needs for PipeWire once setup.
  • 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

Most discussions about how to move forward are currently happening in #gentoo-desktop on IRC between leio, sam, and i-garrison. Help is welcome!

OpenRC

  • OpenRC users are forcefully migrated if using an XDG-compliant desktop environment because of the autostart script installed to /etc/xdg/autostart which will run /usr/bin/gentoo-pipewire-launcher.
  • 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 systemctl --user ... 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:
  • 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.

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 media-video/pipewire was introduced to implement screen capture via USE screencast 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 screencast 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 sound-server to media-video/pipewire. Scope of pipewire sound server function controlled by IUSE sound-server 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 media-video/pipewire with proper blocker in media-sound/pulseaudio-daemon 

RDEPEND="!media-video/pipewire[sound-server(+)]"

Whether IUSE sound-server 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 sound-server on media-video/pipewire.

Screen capture function via USE screencast 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 sound-server on media-video/pipewire.

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

While re-emerging pipewire package a blocker would be resolved to uninstall media-sound/pulseaudio-daemon package.

Use case: existing pulseaudio user installs pipewire for screen capture.

Depending on user choice wrt USE sound-server for pipewire package, either pulseaudio-daemon or pipewire[sound-server] would be emerged.

Screen capture function via USE screencast 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 sound-server on media-video/pipewire 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

Retrieved from "https://wiki.gentoo.org/index.php?title=User:Sam/PipeWire_changes&oldid=1075508"