PipeWire

PipeWire is a Article description::low-latency and graph-based processing engine and a server for interfacing with audio and video devices that can be used to support use cases currently handled by ALSA, PulseAudio and/or JACK. Interested users should understand that as of early 2021 PipeWire is still in active development and not everything is fully integrated, tested or even implemented. Replacing existing solutions on Gentoo is possible but the experience is currently not guaranteed to be perfect or even free of known paper-cuts.

Some key features include:
 * Minimal latency capture/playback of audio and video
 * Real-time multimedia processing
 * Multi-process architecture allowing multimedia content sharing between applications
 * Seamless support for PulseAudio, JACK, ALSA, and GStreamer
 * applications sandboxing support with Flatpak

Emerge
To emerge PipeWire one can either issue:

or set the  USE flag on ebuilds that have it e.g. by adding it to global USE and then rebuilding changed packages:

which should pull in media-video/pipewire as dependency.

Configuration
Global PipeWire configuration can be changed by editing. Additionally PipeWire recognizes multiple environment variables that allow these settings to be changed per-user or individual command.

Files under are responsible for individual PipeWire plugins and their integration into usable setups but there is currently no known reason for the end-user to change anything in that folder.

In principle existing PulseAudio or JACK tools can be used to change the configuration of their respective interfaces when PipeWire is set up to behave as a JACK and/or PulseAudio server.

systemd
PipeWire provides socket and service files when built with the  USE flag. The following systemctl command enables systemd's socket activation of PipeWire for the current user:

The socket activation only starts the service when required, which is usually sufficient. Alternatively the user service can be always started when the user logs in by replacing pipewire.socket with pipewire.service:

In both cases, the `--now` flag is optional but probably safe to use as starting PipeWire with default configuration merely allows using new interfaces but does not change the existing ones i.e. non-PipeWire clients continue using the same libraries and services they were using previously. To also replace PulseAudio and/or JACK, one must additionally follow the appropriate instructions elsewhere in this page.

OpenRC with a display manager (e.g. SDDM, LightDM, GDM, etc)
While it has not been tested by this Wiki writer [please do update this after confirming it works], it may be sufficient to add the following line to the file which all known display managers source as part of user login procedure:

OpenRC without a display manager (i.e. startx et al) but on a desktop profile
When elogind is in use, the only difference between these and using a desktop manager as described above is the filename - for startx and its derivatives that internally call startx the file to edit is which is used as an example later here; Sway users will probably want to add it to their Sway configuration or maybe use an autostart .desktop file (assumed to be supported but not verified):

OpenRC without a display manager and not using elogind (not supported by Gentoo!)
The user must ensure there is a viable D-Bus session active:

The user must ensure that XDG_RUNTIME_DIR is set. This is usually managed by a systemd-specific Pluggable Authentication Module and the  service. Likewise elogind should manage the creation.

If not, the user must create the require directory and set the environmental variable

The PipeWire executable must also be called:

systemd
First disable PulseAudio user service (safe to do even if user service was not in use) and then enable PipeWire and PipeWire-Pulse sockets:

Optionally one can also mask PulseAudio user service and socket but it should be noted that this will not help much if PulseAudio configuration permits autostart [as is default]:

OpenRC
To have PipeWire to act as a PulseAudio user daemon/server, un-comment the pipewire-pulse line in the main configuration file:

Verifying that it worked
To check whether PipeWire is now acting as the PulseAudio user daemon/server, use the pactl command in a Bash compatible shell (no the code below is not a typo - we had to avoid piping commands as Gentoo Wiki templates run on the pipe symbol):

Replacing JACK
To have JACK clients routed through PipeWire, currently the only method supported by Gentoo is to run them via pw-jack which uses LD_PRELOAD to redirect clients from JACK's original libraries to PipeWire's alternatives:

It should be noted that either due to PipeWire incompleteness or Gentoo configuration shortcomings, not every client will work. Some may even ungracefully exit due to missing symbols. It will likely also require re-configuration of JACK clients, because they will attempt to use their old configuration files, if such exist.

Alternatively it should be possible to have PipeWire connect to a real jackd and act as a gateway for non-JACK applications but, unless there already is a working JACK setup, this is not recommended for the overall worse user experience with JACK.

CS:GO (and other games using the Valve's Source engine)
The default sound buffer length is 0.025. This can sometimes be too low causing cracking audio. PulseAudio automatically increases the buffersize. It is undecided whether PipeWire will in future automatically increase the buffer length

for now, the workaround is to increase the size of the buffer from within CSGO "snd_mixahead is the length of the sound buffer in seconds, so 0.05 is 50ms (0.10, edited: 25ms is the default). This is essentially the audio delay, so reducing it gives better synchronization. Not all hardware can handle this low of a buffer setting though, so if you hear any crackling or pops at 0.05, increase this setting by 0.01 until the crackling/pops disappear."

Increasing RLIMIT_MEMLOCK for PulseAudio clients (systemd specific)
In case if messages such as this are observed:

one can adjust the amount of memory that pipewire-pulse process can lock via:

and add in the blank space in the upper section of the editor window (not forgetting to save the file afterwards, of course):

If the system is shared between multiple users, this has to be done for each user (or the created override file has to be copied over with appropriate permissions).

Finally, to have the override applied one must reload the configuration and then restart the service:

The current unit default is set to  (same as 128K) by the Gentoo package which as of PipeWire 0.3.21 seems to allow for 1 PulseAudio client (subsequent clients will receive buffers backed by unlocked memory). Increasing the number to 256K as seen above should allow for 3 clients with buffers locked to memory at the same time.

While this is just a conjecture, it seems very likely that the LimitMEMLOCK which sets the per-unit hard limit (and implicitly also the LimitMEMLOCKSoft to the same value) must be within the bounds set on the user in question, which is 64 kilobytes for users without realtime capability. To actually have the default 128K or any other value above 64 kilobytes applied, one therefore must set a new limit for non-system accounts:

The new limits are only in effect on new logins, therefore the user must log out and back in. This is usually enough but if pipewire-pulse.service survived the logout, then it must be manually restarted as described previously in this subsection.

Increasing RLIMIT_MEMLOCK for JACK clients (and PulseAudio clients with OpenRC)
Unlike the case of PulseAudio clients, for which the user service does memory locking of buffers, JACK clients do it themselves. In the likely event that the clients report being unable to lock memory, in addition to the hard limit (max permitted value) described in previous sub-section on PulseAudio RLIMIT_MEMLOCK, the soft limit (the default value) must also be raised:

Bluetooth
By default, Bluetooth support is disabled to avoid clashes with PulseAudio's Bluetooth stack since currently the main use case is as an addition to not a replacement for PA. Uncomment PipeWire's bluez5 module for Bluetooth devices to be listed:

{{FileBox|filename=/etc/pipewire/media-session.d/media-session.conf|1= ... modules = { ...   default = [ ...       bluez5          # bluetooth support ...   ]    ... }}

then run: