pipewire.conf(5) | File Formats Manual | pipewire.conf(5) |
pipewire.conf - pipewire.conf
The PipeWire server configuration file
$XDG_CONFIG_HOME/pipewire/pipewire.conf
/etc/pipewire/pipewire.conf
/usr/share/pipewire/pipewire.conf
/usr/share/pipewire/pipewire.conf.d/
/etc/pipewire/pipewire.conf.d/
$XDG_CONFIG_HOME/pipewire/pipewire.conf.d/
PipeWire is a service that facilitates sharing of multimedia content between devices and applications.
On startup, the daemon reads a main configuration file to configure itself. It executes a series of commands listed in the config file.
The config file is looked up in the order listed in the SYNOPSIS. The environment variables PIPEWIRE_CONFIG_DIR, PIPEWIRE_CONFIG_PREFIX and PIPEWIRE_CONFIG_NAME can be used to specify an alternative config directory, subdirectory and file respectively.
Other PipeWire configuration files generally follow the same lookup logic, replacing pipewire.conf with the name of the particular config file.
All *.conf files in the pipewire.conf.d/ directories are loaded and merged into the configuration. Dictionary sections are merged, overriding properties if they already existed, and array sections are appended to. The drop-in files have same format as the main configuration file, but only contain the settings to be modified.
As the pipewire.conf configuration file contains various parts that must be present for correct functioning, using drop-in files for configuration is recommended.
A configuration file ~/.config/pipewire/pipewire.conf.d/custom.conf to change the value of the default.clock.min-quantum setting in pipewire.conf:
context.properties = { default.clock.min-quantum = 128 }
The configuration file is in 'SPA' JSON format.
The configuration file contains top-level keys, which are the sections. The value of a section is either a dictionary, { }, or an array, [ ]. Section and dictionary item declarations have KEY = VALUE form, and are separated by whitespace. For example:
context.properties = { # top-level dictionary section key1 = value # a simple value key2 = { key1 = value1 key2 = value2 } # a dictionary with two entries key3 = [ value1 value2 ] # an array with two entries key4 = [ { k = v1 } { k = v2 } ] # an array of dictionaries } context.modules = [ # top-level array section value1 value2 ]
The configuration files can also be written in standard JSON syntax, but for easier manual editing, the relaxed 'SPA' variant is allowed. In 'SPA' JSON:
context.properties
context.spa-libs
context.modules
context.objects
context.exec
This array used to contain an entry to start the session manager but this mode of operation has since been demoted to development aid. Avoid starting a session manager in this way in production environment.
node.rules
device.rules
Available PipeWire properties in context.properties and possible default values.
clock.power-of-two-quantum = true
context.data-loop.library.name.system
core.daemon = false
core.name = pipewire-0
cpu.zero.denormals = false
default.clock.rate = 48000
default.clock.allowed-rates = [ ]
default.clock.min-quantum = 32
default.clock.max-quantum = 8192
default.clock.quantum = 1024
default.clock.quantum-limit = 8192
default.clock.quantum-floor = 4
default.video.width
default.video.height
default.video.rate.num
default.video.rate.denom
library.name.system = support/libspa-support
link.max-buffers = 64
log.level = 2
mem.allow-mlock = true
mem.warn-mlock = false
mem.mlock-all = false
settings.check-quantum = false
settings.check-rate = false
support.dbus = true
vm.overrides = { default.clock.min-quantum = 1024 }
context.modules.allow-empty = false
The context properties may also contain custom values. For example, the context.modules and context.objects sections can declare additional conditions that control whether a module or object is loaded depending on what properties are present.
SPA plugins are loaded based on their factory-name. This is a well known name that uniquely describes the features that the plugin should have. The context.spa-libs section provides a mapping between the factory-name and the plugin where the factory can be found.
Factory names can contain a wildcard to group several related factories into one plugin. The plugin is loaded from the first matching factory-name.
context.spa-libs = { audio.convert.* = audioconvert/libspa-audioconvert avb.* = avb/libspa-avb api.alsa.* = alsa/libspa-alsa api.v4l2.* = v4l2/libspa-v4l2 api.libcamera.* = libcamera/libspa-libcamera api.bluez5.* = bluez5/libspa-bluez5 api.vulkan.* = vulkan/libspa-vulkan api.jack.* = jack/libspa-jack support.* = support/libspa-support video.convert.* = videoconvert/libspa-videoconvert }
PipeWire modules to be loaded. See libpipewire-modules(7).
context.modules = [ #{ name = MODULENAME # ( args = { KEY = VALUE ... } ) # ( flags = [ ( ifexists ) ( nofail ) ] ) # ( condition = [ { KEY = VALUE ... } ... ] ) #} # ]
name
args = { }
flags = [ ]
condition = [ ]
The context.objects section allows you to make some objects from factories (usually created by loading modules in context.modules).
context.objects = [ #{ factory = <factory-name> # ( args = { <key> = <value> ... } ) # ( flags = [ ( nofail ) ] ) # ( condition = [ { <key> = <value> ... } ... ] ) #} ]
This section can be used to make nodes or links between nodes.
factory
args = { }
flags = [ ]
condition = [ ]
This fragment creates a new dummy driver node, but only if core.daemon property is true:
context.objects = [ { factory = spa-node-factory args = { factory.name = support.node.driver node.name = Dummy-Driver node.group = pipewire.dummy priority.driver = 20000 }, condition = [ { core.daemon = true } ] } ]
The context.exec section can be used to start arbitrary commands as part of the initialization of the PipeWire program.
context.exec = [ #{ path = <program-name> # ( args = "<arguments>" ) # ( condition = [ { <key> = <value> ... } ... ] ) #} ]
path
args
condition
The following fragment executes a pactl command with the given arguments:
context.exec = [ { path = "pactl" args = "load-module module-always-sink" } ]
Some configuration file sections contain match rules. This makes it possible to perform some action when an object (usually a node or stream) is created/updated that matches certain properties.
The general rules object follows the following pattern:
<rules> = [ { matches = [ # any of the following sets of properties are matched, if # any matches, the actions are executed { # <key> = <value> # all keys must match the value. ! negates. ~ starts regex. #application.process.binary = "teams" #application.name = "~speech-dispatcher.*" # Absence of property can be tested by comparing to null #pipewire.sec.flatpak = null } { # more matches here... } ... ] actions = { <action-name> = <action value> ... } } ]
The rules is an array of things to match and what actions to perform when a match is found.
The available actions and their values depend on the specific rule that is used. Usually it is possible to update some properties or set some quirks on the object.
The PipeWire Developers <https://gitlab.freedesktop.org/pipewire/pipewire/issues>; PipeWire is available from <https://pipewire.org>
pipewire(1), pw-mon(1), libpipewire-modules(7) pipewire-pulse.conf(5) pipewire-client.conf(5)
1.0.5 | PipeWire |