pipewire-pulse

Start the daemon with default settings

$ pipewire-pulse

$ pipewire-pulse [[-c|--config]] [path/to/pipewire-pulse.conf]

$ pipewire-pulse [[-v|--verbose]]

$ pipewire-pulse [[-h|--help]]

pipewire-pulse [options]

--help
    Displays a short help message and exits.

--version
    Prints the PipeWire version information and exits.

--disable-shm
    Disables the use of shared memory for data transport. This might affect performance but can be useful in certain virtualized environments or for troubleshooting.

--debug
    Enables verbose debug logging, providing detailed output useful for diagnosing issues.

The pipewire-pulse command is not a standalone application for direct user interaction, but rather a crucial component of the PipeWire multimedia server. It functions as a daemon that provides a compatibility layer for PulseAudio applications.

Essentially, pipewire-pulse allows existing software designed to work with PulseAudio to seamlessly operate on systems using PipeWire as their primary audio backend. When an application tries to connect to PulseAudio, pipewire-pulse intercepts these requests and translates them into PipeWire calls, routing the audio through the PipeWire server. This ensures a smooth transition for users and developers from PulseAudio to PipeWire without requiring applications to be rewritten.

It's typically launched and managed by system services (like systemd user services) or session managers (WirePlumber) upon user login, running in the background to handle all PulseAudio client connections.

pipewire-pulse acts as a proxy; its behavior and configuration are largely governed by the underlying PipeWire configuration files (e.g., /etc/pipewire/pipewire-pulse.conf). Direct command-line options for fine-tuning are limited.

Running both a native PulseAudio daemon and pipewire-pulse simultaneously can lead to conflicts and undefined behavior, as both attempt to bind to the same sockets and provide the same service. Systems usually configure one or the other as the active audio backend.

While highly compatible, some very specific or esoteric PulseAudio features might not be fully replicated, though this is rare for typical desktop use cases.

The behavior of pipewire-pulse can also be influenced by various environment variables, many of which are inherited from the main PipeWire daemon. Notable examples include PIPEWIRE_DEBUG (for logging levels), PIPEWIRE_CONFIG_DIR (to specify an alternative configuration directory), and PIPEWIRE_MODULE_DIR (for module loading paths). These are typically set system-wide or by the service manager.

Users rarely execute pipewire-pulse directly from the command line. Instead, it is almost universally managed by a system's init system, most commonly systemd, through a user service (e.g., pipewire-pulse.service). Session managers like WirePlumber (which replaced pipewire-media-session) are responsible for starting and stopping this component as part of the user's audio session, dynamically configuring it based on system events and user preferences.

The PipeWire project was initiated by Red Hat in 2017 with the goal of creating a modern, unified multimedia framework for Linux, addressing shortcomings of existing systems like PulseAudio and JACK. The development of pipewire-pulse was critical to its success and adoption. By providing a robust PulseAudio compatibility layer, pipewire-pulse allowed distributions and users to transition to PipeWire without breaking compatibility with thousands of existing applications that relied on the PulseAudio API. This seamless migration path has been a key factor in PipeWire's rapid uptake as the default audio server in many major Linux distributions.

pipewire(1), wireplumber(1), pulseaudio(1), alsa(4)