From Gentoo Wiki
(Redirected from Pipewire)
Jump to:navigation Jump to:search
PipeWire is still in active development. Some things may still not be fully integrated, tested, or implemented, and there may be large changes. It can work well for some, though the experience is not guaranteed to be perfect, free of issues, or bugs.

PipeWire is a 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.



CONFIG_SND_PROC_FS and CONFIG_SND_VERBOSE_PROCFS are needed for newer versions of media-video/wireplumber to work.

Device Drivers  --->
    <*> Sound card support  --->
        <*> Advanced Linux Sound Architecture  --->
            [*]   Sound Proc FS Support
            [*]     Verbose procfs contents

USE flags

To use PipeWire as a sound server, specify the sound-server USE flag on media-video/pipewire.

When using PipeWire as a replacement for the PulseAudio sound server:

  1. Specify the -daemon USE flag on media-sound/pulseaudio, and ensure media-sound/pulseaudio-daemon is not installed. This is necessary to avoid issues resulting from running more than one sound server.
  2. Ensure media-libs/libpulse 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 media-sound/pulseaudio-daemon package, the media-sound/pulseaudio 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 pipewire binary. On other profiles, if using OpenRC, permissions requirements might also need the elogind USE flag on the media-video/wireplumber package, together with sys-auth/elogind 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.

USE flags for media-video/pipewire Multimedia processing graphs

X Enable audible bell for X11
bluetooth Enable Bluetooth Support
dbus Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)
doc Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally
echo-cancel Enable WebRTC-based echo canceller via media-libs/webrtc-audio-processing
extra Build pw-cat/pw-play/pw-record
ffmpeg Enable ffmpeg/libav-based audio/video codec support
flatpak Enable Flatpak support
gsettings Use gsettings (dev-libs/glib) to read/save used modules (useful for e.g. media-sound/paprefs
gstreamer Add support for media-libs/gstreamer (Streaming media)
jack-client Install a plugin for running PipeWire as a JACK client
jack-sdk Use PipeWire as JACK replacement
lv2 Allow loading LV2 plugins via media-libs/lv2
modemmanager Combined with USE=bluetooth, allows PipeWire to perform telephony on mobile devices.
pipewire-alsa Replace PulseAudio's ALSA plugin with PipeWire's plugin
readline Enable support for libreadline, a GNU line-editing library that almost everyone wants
sound-server Provide sound server using ALSA and bluetooth devices
ssl Enable raop-sink support (needs dev-libs/openssl)
system-service Install systemd unit files for running as a system service. Not recommended.
systemd Enable use of systemd-specific libraries and features like socket activation or session tracking
test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
v4l Enable support for video4linux (using linux-headers or userspace libv4l libraries)
zeroconf Support for DNS Service Discovery (DNS-SD)


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

root #emerge --ask --verbose --changed-use --update --deep @world

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

root #emerge --ask media-video/pipewire

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 media-video/wireplumber package provides the wireplumber.service systemd service and the wireplumber binary used by gentoo-pipewire-launcher.

root #emerge --ask media-video/wireplumber


PipeWire is still in heavy development - configuration paths, options and defaults can change from one minor release to another - if things on the system do not align with documentation, double check or at least make a backup before making changes.
Detailed, non Gentoo-specific, configuration documentation can be found at the project's official wiki.

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

Global PipeWire configuration can be changed by editing the /etc/pipewire/pipewire.conf file, and ~/.config/pipewire/pipewire.conf may be used for per-user configuration. /etc/pipewire/pipewire.conf is not installed by default, but can be created by copying /usr/share/pipewire/pipewire.conf:

root #cp /usr/share/pipewire/pipewire.conf /etc/pipewire/pipewire.conf

Note that this 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 sys-auth/rtkit package may need to be installed.

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.

The following sections describe configuration of PipeWire as a sound server.


PipeWire provides socket and service files when built with the systemd 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.

user $systemctl --user disable --now pulseaudio.socket pulseaudio.service

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

user $systemctl --user enable --now pipewire.socket pipewire-pulse.socket wireplumber.service

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:

user $systemctl --user enable --now pipewire.service

In these cases, the --now 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.


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.

In all cases where systemd user services are not being used, PipeWire must be started before anything that might try to connect to any sound input or output, such as a volume monitoring applet.
Older versions of PipeWire (<0.3.39) worked by calling pipewire directly, but this is no longer recommended/correct.



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 ~/.bash_profile, ~/.zprofile, etc.:

# Ensure XDG_RUNTIME_DIR is set
export XDG_RUNTIME_DIR=$(mktemp -d /tmp/$(id -u)-runtime-dir.XXX)

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 dbus-launch, which will set DBUS_SESSION_BUS_ADDRESS for the session. For example, if starting X via startx, the final line of ~/.xinitrc could be:

FILE ~/.xinitrc
exec dbus-launch --exit-with-session bspwm

Note that the exec means that no subsequent commands in that file will be executed until the session ends. Any commands needing to be run from within the new session should be added to the WM's configuration/setup file, e.g. ~/.config/bspwm/bspwmrc.

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

user $dbus-launch --exit-with-session sway

Display manager environments (SDDM, LightDM, GDM, etc)

Gentoo's PipeWire package installs the /etc/xdg/autostart/pipewire.desktop 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 ~/.xprofile file, by adding:

FILE ~/.xprofile
gentoo-pipewire-launcher &

Wayland / Sway / Window Managers

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

For Sway in particular, edit ~/.config/sway/config to add:

FILE ~/.config/sway/config
gentoo-pipewire-launcher &

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

FILE ~/.config/i3/config
gentoo-pipewire-launcher &

Verifying PulseAudio server emulation

user $LANG=C pactl info | grep "Server Name"
Server Name: PulseAudio (on PipeWire 0.3.39)

Setting 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.

To change the sample rate, uncomment and change this line:

FILE pipewire.conf
default.clock.rate = 48000

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:

FILE pipewire.conf
default.clock.allowed-rates = [48000 44100 96000]

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

Adding multi user support

The default configuration only allows the current user (who started pipewire-pulse) to play audio.

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

user $cp -r /usr/share/pipewire/ /etc/
user $$EDITOR /etc/pipewire/pipewire-pulse.conf

Locate server.address = [ 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:

user $pw-jack qsynth
Existing JACK users are likely to have realtime capability set up but new users are advised to raise the RLIMIT_MEMLOCK value from Gentoo's default of 64 kilobytes to 256 kilobytes on all PipeWire users that want to use its JACK emulation. For instructions on how to achieve that please see the subsection on that below (also listed in the table of contents for this page). Failure to do this will likely cause at least occasional buffer underuns (xruns) as a single page fault is likely to spend half to the entire length of a buffer just in kernel time to resolve.

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 media-sound/ardour might be resolved using a Wireplumber script:

FILE ~/.config/wireplumber/main.lua.d/latency.lua
table.insert(alsa_monitor.rules, {
  matches = {
      -- replace device as described below
      { "node.name", "equals", "device" },
  apply_properties = {
    -- If 64 doesn't work, try bigger values that are a multiple of 2 (128, 256, 512, 1024, 2048, etc.)
    ["api.alsa.headroom"] = 64,


user $wpctl status

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

user $wpctl inspect <number> | grep node.name

This should output one line, for example * node.name = "alsa_output.usb-Lenovo_ThinkPad.analog-stereo". Replace device in the script with the device from the output (in this example it would be alsa_output.usb-Lenovo_ThinkPad.analog-stereo). 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)

It appears that this issue has been resolved by a patch by Valve in early 2021. If the issue is no longer present without any fixes applied, then please delete this subsection entirely.

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[1][2]:

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:

FILE /etc/security/limits.d/50-custom.conf
# This both raises the max and sets the default lockable memory limit of every process running under a non-system account (except for nobody) from default 64 to 256 kilobytes (in increments of page size)
1000:65533      -    memlock 256


PipeWire should already be enabling the bluez5 module when built with the pulseaudio USE flag. Please check if it's being set system-wide as PulseAudio API for clients is not going anywhere in a hurry.

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:

FILE /etc/pipewire/media-session.d/media-session.conf
modules = {
    default = [
        bluez5          # bluetooth support

Then run:

user $systemctl --user restart pipewire-pulse.service

Restarting PipeWire after crash (with OpenRC)

When PipeWire crashes, all sound devices disappear. Three processes need to be created:

  1. pipewire
  2. wireplumber
  3. pipewire -c pipewire-pulse.conf

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

user $/usr/bin/gentoo-pipewire-launcher &

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 #OpenRC section for how to ensure a D-Bus session bus is running for your particular environment.

See also

External resources