PipeWire 1.2.5
|
This module implements a complete PulseAudio server on top of PipeWire. This is only the server implementation, client are expected to use the original PulseAudio client library. This provides a high level of compatibility with existing applications; in fact, all usual PulseAudio tools such as pavucontrol, pactl, pamon, paplay should continue to work as they did before.
This module is usually loaded as part of a standalone pipewire process, called pipewire-pulse, with the pipewire-pulse.conf config file.
The pulse server implements a sample cache that is otherwise not available in PipeWire.
libpipewire-module-protocol-pulse
The module arguments can be the contents of the pulse.properties but it is recommended to make a separate pulse.properties section in the config file so that overrides can be done.
A config section with server properties can be given.
The addresses the server listens on when starting. Uncomment the tcp:4713
entry to also make the server listen on a tcp socket. This is equivalent to loading libpipewire-module-native-protocol-tcp
.
There is also a slightly more verbose syntax with more options:
Use client.access
to use one of the access methods to restrict the permissions given to clients connected via this address.
By default network access is given the "restricted" permissions. The session manager is responsible for assigning permission to clients with restricted permissions (usually read-only permissions).
The DBus name to reserve for the server. If you have multiple servers, you might want to change the name.
By default, clients are allowed to load and unload modules. You can disable this feature with this option.
The minimum amount of data to request for clients. The client requested values will be clamped to this value. Lowering this value together with tlength can decrease latency if the client wants this, but increase CPU overhead.
The default amount of data to request for clients. If the client does not specify any particular value, this default will be used. Lowering this value together with tlength can decrease latency but increase CPU overhead.
The target amount of data to buffer on the server side. If the client did not specify a value, this default will be used. Lower values can decrease the latency.
The minimum allowed size of the capture buffer before it is sent to a client. The requested value of the client will be clamped to this. Lowering this value can reduce latency at the expense of more CPU usage.
The default size of the capture buffer before it is sent to a client. If the client did not specify any value, this default will be used. Lowering this value can reduce latency at the expense of more CPU usage.
The minimum quantum (buffer size in samples) to use for pulseaudio clients. This value is calculated based on the frag and req/tlength for record and playback streams respectively and then clamped to this value to ensure no pulseaudio client asks for too small quantums. Lowering this value might decrease latency at the expense of more CPU usage.
Some modules will default to this format when no other format was given. This is equivalent to the PulseAudio default-sample-format
option in /etc/pulse/daemon.conf
.
Some modules will default to this channelmap (with its number of channels). This is equivalent to the PulseAudio default-sample-channels
and default-channel-map
options in /etc/pulse/daemon.conf
.
When a stream uses the FIX_FORMAT flag, fixate the format to this value. Normally the format would be fixed to the sink/source that the stream connects to. When an invalid format (null or "") is set, the FIX_FORMAT flag is ignored.
When a stream uses the FIX_RATE flag, fixate the sample rate to this value. Normally the rate would be fixed to the sink/source that the stream connects to. When a 0 rate is set, the FIX_RATE flag is ignored.
When a stream uses the FIX_CHANNELS flag, fixate the channels to this value. Normally the channels would be fixed to the sink/source that the stream connects to. When an invalid position (null or "") is set, the FIX_CHANNELS flag is ignored.
Some clients are not sending data when they should and cause underruns. When setting this option such clients will be set to paused if they underrun for the given amount of seconds. This makes sure that sinks can suspend and save battery power. When the client resumes, it will unpause again. A value of 0 disables this feature.
As part of the server startup sequence, a set of commands can be executed. Currently, this can be used to load additional modules into the server.
The pulse.properties can be dynamically updated with rules. It supports an update-props
action. The matches will be performed on the values in context.properties.
In the above example, when running in a VM, the rule will override the properties in pulse.properties with the given values. This might be interesting because VMs usually can't support the low latency settings that are possible on real hardware.
Streams created by module-protocol-pulse will use the stream.properties section and stream.rules sections as usual.
The pulse protocol module supports generic config rules. It supports a pulse.rules section with a quirks
and an update-props
action.
The quirks action takes an array of quirks to apply for the client.
force-s16-info
makes the sink and source introspect code pretend that the sample format is S16 (16 bits) samples. Some application refuse the sink/source if this is not the case.remove-capture-dont-move
Removes the DONT_MOVE flag on capture streams. Some applications set this flag so that the stream can't be moved anymore with tools such as pavucontrol.block-source-volume
blocks the client from updating any source volumes. This can be used to disable things like automatic gain control.block-sink-volume
blocks the client from updating any sink volumes.Takes an object with the properties to update on the client. Common actions are to tweak the quantum values.