mirror of
https://gitlab.freedesktop.org/pipewire/pipewire
synced 2024-09-06 00:40:34 +00:00
e1672f9762
Allow one of "XEWIDT" to refer to none, errors, warnings, info, debug and trace, respectively because they're immediately recognizable. Well, except maybe the X. PIPEWIRE_DEBUG="I" is equivalent to PIPEWIRE_DEBUG="3" for example.
148 lines
4.8 KiB
Plaintext
148 lines
4.8 KiB
Plaintext
/** \page page_daemon PipeWire Daemon
|
||
|
||
The PipeWire daemon is the central process that manages data exchange between
|
||
devices and clients.
|
||
|
||
Typically general, users run one PipeWire daemon that listens for incoming
|
||
connections and manages devices. Clients (including the \ref
|
||
page_session_manager) are separate processes that talk to the daemon using the
|
||
PipeWire socket (default: `$XDG_RUNTIME_DIR/pipewire-0`). This approach
|
||
provides provides address-space separation between the privileged daemon and
|
||
non-privileged clients.
|
||
|
||
\dot
|
||
digraph pw {
|
||
compound=true;
|
||
node [shape="box"];
|
||
|
||
subgraph cluster_pw {
|
||
rankdir="TB";
|
||
label="PipeWire daemon";
|
||
style="dashed";
|
||
|
||
subgraph cluster_prot_native {
|
||
label="pipewire-module-protocol-native";
|
||
style="solid";
|
||
socket [label="$XDG_RUNTIME_DIR/pipewire-0"];
|
||
mod_impl [label="module implementation"];
|
||
|
||
socket -> mod_impl;
|
||
}
|
||
core [label="PipeWire Core"];
|
||
alsa [label="PipeWire ALSA support"];
|
||
|
||
mod_impl -> core;
|
||
core -> alsa;
|
||
}
|
||
|
||
kernel
|
||
|
||
client1 [ label="Media Player" ];
|
||
client2 [ label="Audio Software" ];
|
||
sm [ label="Session Manager", style="dotted" ];
|
||
|
||
client1 -> socket;
|
||
client2 -> socket;
|
||
sm -> socket;
|
||
alsa -> kernel;
|
||
}
|
||
\enddot
|
||
|
||
As shown above, the protocol is handled by the \ref
|
||
page_module_protocol_native. From PipeWire's point-of-view this module is just
|
||
another module.
|
||
|
||
\section sec_config Configuration Files
|
||
|
||
On startup, the daemon reads a configuration file to configure itself.
|
||
It executes a series of commands listed in the config file. The lookup order
|
||
for configuration files are:
|
||
|
||
- `$XDG_CONFIG_HOME/pipewire/pipewire.conf` (usually `$HOME/.config/pipewire/pipewire.conf`)
|
||
- `$sysconfdir/pipewire/pipewire.conf` (usually `/etc/pipewire/pipewire.conf`)
|
||
- `$datadir/pipewire/pipewire.conf` (usually `/usr/share/pipewire/pipewire.conf`)
|
||
|
||
The first configuration file found is loaded, the PipeWire daemon does not
|
||
currently combine configuration files.
|
||
|
||
The environment variables `PIPEWIRE_CONFIG_DIR`, `PIPEWIRE_CONFIG_PREFIX`
|
||
and `PIPEWIRE_CONFIG_NAME` can be used to specify an alternative config
|
||
directory, subdirectory and filename, respectively.
|
||
|
||
\subsection sec_config_format Configuration File Format
|
||
|
||
PipeWire's configuration file format is JSON. In addition to true JSON,
|
||
PipeWire also understands a more compact JSON representation where
|
||
`"` can be omitted around strings, no trailing commas are required and
|
||
`:` or `=` can be used to separate object keys from their values.
|
||
Also, `#` can be used to start a comment until the end of the line.
|
||
|
||
The configuration file format is grouped into sections. A section is
|
||
either a dictionary (`{}`) or an array (`[]`). Dictionary and array entries
|
||
are separated by whitespace and may be simple value assignment, an array or
|
||
a dictionary. For example:
|
||
|
||
```
|
||
# A dictionary section
|
||
context.properties = {
|
||
# Keys often have a dot notation
|
||
core.daemon = true
|
||
}
|
||
|
||
# An array section containing three dictionary objects
|
||
context.modules = [
|
||
# a dictionary object with one key assigned to a string
|
||
{ name = libpipewire-module-protocol-native }
|
||
{ name = libpipewire-module-profiler }
|
||
|
||
# a dictionary object with two keys, one assigned to a string
|
||
# the other one to an array of strings
|
||
{ name = libpipewire-module-portal
|
||
flags = [ ifexists nofail ]
|
||
}
|
||
]
|
||
```
|
||
|
||
Allowed configuration file sections are:
|
||
|
||
- **context.properties** (dictionary): These properties configure the
|
||
pipewire instance.
|
||
|
||
- **context.spa-libs** (dictionary): Maps plugin features with globs to a
|
||
spa library.
|
||
|
||
- **context.modules** (array): Each entry in the array is a dictionary with
|
||
the name of the module to load, including optional args and flags. Most
|
||
modules support being loaded multiple times.
|
||
|
||
- **context.objects** (array): Each entry in the array is a dictionary con‐
|
||
taining the factory to create an object from and optional extra argu‐
|
||
ments specific to that factory.
|
||
|
||
- **context.exec** (array): Each entry in the array is dictionary containing
|
||
the path of a program to execute on startup and optional args. This ar‐
|
||
ray usually contains an entry to start the session manager.
|
||
|
||
|
||
\section sec_logging Logging
|
||
|
||
The `PIPEWIRE_DEBUG` environment variable can be used to enable
|
||
more debugging. The format is:
|
||
|
||
`<level>[<category>,<category>,...]`
|
||
|
||
- `<level>` specifies the log level:
|
||
+ `X` or `0`: no logging is enabled
|
||
+ `E` or `1`: Error logging is enabled
|
||
+ `W` or `2`: Warnings are enabled
|
||
+ `I` or `3`: Informational messages are enabled
|
||
+ `D` or `4`: Debug messages are enabled
|
||
+ `T` or `5`: Trace messages are enabled. These messages can be logged
|
||
from the realtime threads.
|
||
|
||
- `<category>`: Specifies a string category to enable. Many categories
|
||
can be separated by commas. Current categories are:
|
||
+ `connection`: to log connection messages
|
||
|
||
*/
|