How PipeWire Handles Audio Devices and Routing on Linux

The immediate answer

PipeWire is the audio and video routing service used by many current Linux distributions. For audio, it presents a unified graph in which applications produce or consume streams and hardware devices exist as nodes. PipeWire can move those streams between devices, convert sample rates and formats, and enforce a selected device profile. The exact behavior depends on the installed PipeWire version, the session manager, the distribution integration and the kernel drivers, so recognition of a device by PipeWire is not by itself proof that every application can play or record through it without further routing or permissions.

Hardware recognition and devices

A physical sound device is exposed through ALSA card and PCM device numbering in the kernel. PipeWire discovers that hardware through an ALSA monitor and creates corresponding PipeWire device objects. A PipeWire device can contain one or more profiles. A profile describes a supported mode of operation, such as stereo output only, stereo input only, or simultaneous input and output. Selecting a profile changes which ports are available for that device.

Ports are the usable endpoints on a device: a speaker output, a microphone input, or an internal mixer source such as a loopback or a hardware volume control. Applications do not usually connect directly to a hardware device port. Instead, the session manager creates an application stream node and connects it to a suitable device node according to routing policy.

The PipeWire graph

The PipeWire graph contains nodes for applications, devices and internal filters. Links carry audio between the output and input ports of those nodes. PipeWire can insert format conversion, resampling or channel remapping when two nodes cannot agree on a common format. This means an application may request a format that differs from the hardware format and still work, at the cost of some processing. The graph is not static; nodes and links appear and disappear as applications start, stop or change their requested streams.

The session manager

PipeWire itself provides the media graph and the daemon, while routing policy is normally supplied by a session manager. WirePlumber is the common session manager on many modern distributions, though older or specialized setups may use another implementation. WirePlumber watches for new nodes and decides which device to use, what profile to activate and which ports to connect.

Applications can influence routing through metadata or by asking a desktop portal or sound settings panel to move a stream. A desktop environment that integrates PipeWire may show applications as movable streams and devices as selectable endpoints. In that case, moving the stream is a session-manager operation, not a change to the application's own audio API configuration.

Inspection tools

The command pw-cli is a low-level PipeWire tool that can list objects, inspect parameters and change properties or permissions. The utility pw-dump outputs the current PipeWire state as a large structured description. A focused way to inspect audio objects is:

pw-cli ls Node

This lists graph nodes, including applications and devices. The related utility pw-top shows a live view of nodes, their state and measured or estimated timing information. The exact fields depend on the installed PipeWire version. These tools report the state that PipeWire currently exposes; they do not independently prove that audio is audible or that a microphone signal is being captured by a specific application.

Device profiles and ports

A desktop sound settings panel may offer a device with several profiles. The labels and available options differ between hardware and desktop environments. Where supported, the panel can switch a device between output-only, input-only and duplex modes, or expose a special mode such as high-definition audio or surround output. Changing the profile can disconnect streams that were attached to a port which no longer exists.

Port-level routing is available in tools that present the full PipeWire graph. A port may be unavailable even though a card is present, because the active profile does not include it or because another application has exclusive control of a lower-level PCM device. Such a conflict can appear as a device that is listed but cannot be opened.

Common configuration points

• pipewire.conf and its drop-in directory control daemon behavior, sample-rate handling and some module loading; the exact supported keys depend on the installed version.
• wireplumber configuration controls routing policy, device selection rules and stream behavior through Lua-based configuration files.
• also controls whether PipeWire is used as the compatibility layer for older applications. When ALSA compatibility is active, applications using the ALSA library can appear as PipeWire nodes and be routed like native PipeWire clients.

End-to-end behavior

A device that appears in kernel audio listings has been detected by a driver. If it also appears in pw-cli output, PipeWire has discovered and advertised it. That is still one step short of successful audio use: the session manager must choose an appropriate profile, the application must open a stream, permissions must allow access, and the final connection must reach a port that is active and unmuted.

For example, a USB audio interface may appear as a PipeWire device while an application configured to use a PulseAudio-compatible sink still cannot hear anything because the stream is routed to an internal dummy or monitor port. In other cases, an application may request a non-default source directly and bypass the session manager's intended device selection. Checking the graph links, not only the device list, is therefore necessary when diagnosing a silent but listed device.