PipeWire

PipeWire is a Article description::low-latency, graph-based, processing engine and server, for interfacing with audio and video devices. It can be used to support use-cases currently handled by ALSA, PulseAudio, and/or JACK, and aims to improve handling of audio and video under Linux.

Some key features of PipeWire 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, with a security model that facilitates interacting containerized applications.

PipeWire currently ships a PipeWire daemon, an example session manager, tools to introspect and use the PipeWire Daemon, a library to develop PipeWire applications and plugins, and the SPA (Simple Plugin API) used by both the PipeWire daemon and the PipeWire library.

Kernel
CONFIG_SND_PROC_FS and CONFIG_SND_VERBOSE_PROCFS are needed for newer versions of to work.

USE flags
To use PipeWire as a sound server, specify the sound-server USE flag on.

Then, if using PipeWire as a replacement for the PulseAudio sound server:


 * 1) Specify the -daemon USE flag on, and ensure  is not installed. This is necessary to avoid issues resulting from running more than one sound server.
 * 2) Ensure  is installed, which will allow PipeWire to emulate a PulseAudio sound server. Not many applications currently support PipeWire's native API.
 * 3) Ensure the pulseaudio USE flag is still set in make.conf.

Note that, although the above will remove the need for the package, the  package will still need to be installed, as it provides the libraries for any software that uses PulseAudio for audio output.

PipeWire requires the presence of a D-Bus session bus and an XDG-compliant environment. Both requirements should be met by a desktop profile; on such systems, starting PipeWire is as simple as running the binary. On other profiles, if using OpenRC, permissions requirements might also need the elogind USE flag on the package, together with  itself.

To enable direct screencasting support on applications offering it, specify the screencast USE flag on the relevant packages. Otherwise, screencasting support may also be provided through the PulseAudio or JACK compatibility layers.

Emerge
Once the USE flags have been specified, rebuild the affected packages:

Alternatively, PipeWire may be emerged independently, though the previous method is usually what is required:

Typically, the WirePlumber session manager should also be installed. WirePlumber is a replacement for pipewire-media-session; refer to this article for an introduction and the details. The package provides the wireplumber.service systemd service and the wireplumber binary used by gentoo-pipewire-launcher.

Configuration
Typically, things work reasonably well out of the box, and PipeWire's system-level configuration is usually best left unmodified.

If configuration is required, PipeWire's configuration files are located at:


 * 1)  - User PipeWire configuration
 * 2)  - System PipeWire configuration
 * 3)  - Sample PipeWire configuration

PipeWire's default configuration tries to use realtime scheduling to increase audio thread priorities. It's recommended that users are in the pipewire group. If the user doesn't have the necessary permissions for this, the configuration will try to use RTKit instead, so the package may need to be installed. This behavior is defined under the  portion of PipeWire's configuration.

PipeWire also recognizes multiple environment variables that allow these settings to be changed, per-user, or for individual commands.

No additional configuration is required to use PipeWire as video server; this functionality is enabled by default.

context.properties
The following configuration options are applied under  in PipeWire's configuration

sample rates
PipeWire uses a global sample rate in the audio processing pipeline. All signals are converted to this sample rate and then converted to the sample rate of the device.

It is also possible to dynamically force a sample rate at runtime see here

Avoid resampling
Since 0.3.33, it is possible to specify up to 16 alternative sample rates. Use the following config option to specify the sample rates:

Note that this not enabled by default because of kernel driver bugs.

According to the PipeWire developer, with the above configuration, no resampling is done when the graph is at a rate which both the client and the device can support.

Screensharing with Chrome
Change "WebRTC PipeWire support" to "Enabled" from chrome://flags

systemd
PipeWire provides socket and service files when built with the  USE flag.

If the PulseAudio user service is enabled, disable it; this is safe to do even if the user service was not in use.

While PipeWire does not appear to utilize the directory beyond the cookie file, it may be a good idea to rename or delete it.

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:

In these cases, the  flag is optional, but probably safe to use, as starting PipeWire with default configuration merely allows using new interfaces and doesn't change the existing ones, i.e. non-PipeWire clients continue using the same libraries and services they were using previously.

OpenRC
There is no truly standardized way (outside of systemd) to load PipeWire when starting a graphical shell, and users need to choose the correct approach based on how their graphical environment is started.

Prerequisites

 * XDG_RUNTIME_DIR

This variable is usually set automatically by systemd-logind, elogind or seatd. Systems that don't use any of these seat management daemons will need to set XDG_RUNTIME_DIR manually, e.g. in, , etc.:


 * DBUS_SESSION_BUS_ADDRESS

This variable is usually set automatically by desktop environments such as GNOME or KDE. Note that a D-Bus session bus is not what is typically being provided by the system D-Bus service, which is instead providing a system bus for things like hardware events, etc.

When running a window manager, such as i3, bspwm or Sway, the WM needs to be started with, which will set DBUS_SESSION_BUS_ADDRESS for the session. For example, if starting X via, the final line of could be:

Note that use of in this context means that no subsequent commands in that file will be executed, as the shell process interpreting the file will be replaced by the  process. Any commands needing to be run from within the new session should be added to the WM's configuration/setup file, e.g..

More generally, can be run directly from the command line:

gentoo-pipewire-launcher
The script starts:

Before doing so, the script terminates any existing PipeWire or WirePlumber instances. For further details, refer to the comments in the script.
 * a PipeWire server;
 * a WirePlumber session manager, required to make use of PipeWire servers; and
 * a 'pipewire-pulse' PipeWire server, required for PulseAudio compatibility.

should be started in an environment which has the DBUS_SESSION_BUS_ADDRESS environment variable set appropriately, i.e. within the context of the program started by.

Display manager environments (SDDM, LightDM, GDM, etc)
Gentoo's PipeWire package installs the autostart file. However, not all display managers make use of autostart files. SDDM in particular does not make use of autostart files.

In such environments, start PipeWire via the file (creating it if necessary), by adding:

Wayland / Sway / Window Managers
The XDG autostart approach should work for Wayland as well as X, but it is not clear whether is necessarily sourced when starting a Wayland session.

For Sway, edit to add:

For dwm, edit to add:

More generally, when using a window manager, a call to needs to be added to the WM's configuration/setup file, e.g.:

Restarting PipeWire and WirePlumber
To restart PipeWire and WirePlumber under OpenRC, e.g. to pick up configuration changes, shut down the existing instances from within the relevant D-Bus session, then run :

Using allows the terminal to be closed without terminating. Where output is directed might depend on the implementation of ; depending on the shell, might be a builtin or an external command (e.g. ), so check the shell's documentation.

Adding multi user support
The default configuration only allows the current user (who started ) to play audio.

For multi-user support, the TCP interface is needed:

Locate  section and uncomment one of the available TCP options.

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.

Stuttering recordings in applications like might be resolved using a Wireplumber script:

Executing outputs the list of devices currently available on the system. The audio device should appear under Audio -> Sinks (unsure which one to pick? Use the one with the star (*) at the beginning. Its your currently used device). Remember this number and execute This should output one line, for example. Replace  in the script with the device from the output (in this example it would be  ). The problem should be resolved after restarting PipeWire. If the issue is not resolved, more information can be found here or here

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; for now the workaround is to increase the size of the application's audio buffer from within CS:GO :

"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 a buffer setting this low though, so if there are any crackling or pops at 0.05, increase this setting by 0.01 until the crackling/pops disappear."

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:

Restarting PipeWire after crash (with OpenRC)
When PipeWire crashes, all sound devices disappear. Three processes need to be created:



Do not run these directly. Instead, start them with:

from the environment with a running D-Bus session bus (e.g. the desktop). An environment with a D-Bus session bus will have the DBUS_SESSION_BUS_ADDRESS variable set; if it is not set, refer to the section for how to ensure a D-Bus session bus is running for your particular environment.

External resources

 * https://bootlin.com/blog/an-introduction-to-pipewire/ - An introduction to PipeWire [June 2022]
 * https://venam.nixers.net/blog/unix/2021/06/23/pipewire-under-the-hood.html - A blog explaining PipeWire from a unique perspective.
 * https://lwn.net/Articles/847412/ - PipeWire: The Linux audio/video bus (LWN).