mirror of
https://gitlab.freedesktop.org/pipewire/wireplumber.git
synced 2026-05-05 07:48:01 +02:00
docs: fix warnings and errors in filter documentation
This commit is contained in:
Julian Bouzas
parent
3eaaae3a45
commit
0c53f9b130
1 changed files with 84 additions and 40 deletions
|
|
@ -72,11 +72,15 @@ For example, the media class of the nodes for a input filter would be:
|
|||
And, if this filter is used between an application stream, and the default audio
|
||||
device, the graph would look like this:
|
||||
|
||||
application stream node -> filter main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
filter stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
application stream node -> filter main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
.. code-block::
|
||||
|
||||
filter stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
|
||||
On the other hand, the media class of the nodes for an output filter would be:
|
||||
|
|
@ -88,11 +92,15 @@ And the same logic is applied if they are used, but in the opposite direction.
|
|||
This is how the graph would look like if an application wants to capture audio
|
||||
from a device that uses an input filter.
|
||||
|
||||
application stream node <- filter main node
|
||||
(Stream/Input/Audio) (Audio/Source)
|
||||
.. code-block::
|
||||
|
||||
filter stream node <- default device node
|
||||
(Stream/Input/Audio) (Audio/Source)
|
||||
application stream node <- filter main node
|
||||
(Stream/Input/Audio) (Audio/Source)
|
||||
|
||||
.. code-block::
|
||||
|
||||
filter stream node <- default device node
|
||||
(Stream/Input/Audio) (Audio/Source)
|
||||
|
||||
Finally, if multiple filters have the same direction, they can also be chained
|
||||
together so that the audio of a filter is sent to the input of the next filter.
|
||||
|
|
@ -109,20 +117,27 @@ are automatically linked by the wirepluber policy in any way we want.
|
|||
Currently, if a filter node is created, wireplumber will check the following
|
||||
optional node properties on the main node:
|
||||
|
||||
- filter.name: the unique name of the filter. WirePlumber will use the
|
||||
"node.link-group" property as filter name if this property is not set.
|
||||
- filter.enabled: Boolean indicating whether the filter should be used at all
|
||||
or not. If it is not set, wireplumber will consider the filter enabled by default.
|
||||
- filter.target: a JSON object that defines the matching properties of the filter's
|
||||
target node. A filter target can never be another filter node (wireplumber will
|
||||
ignore it), and must always be a device node. If this property is not set,
|
||||
WirePlumber will use the default node as target.
|
||||
- filter.before: a JSON array with the filters names that are supposed to be
|
||||
used before this filter. If not set, wireplumber will link the filters by order
|
||||
of creation.
|
||||
- filter.after: a JSON array with the filters names that are supposed to be
|
||||
used after this filter. If not set, wireplumber will link the filters by order
|
||||
of creation.
|
||||
- filter.name:
|
||||
The unique name of the filter. WirePlumber will use the "node.link-group"
|
||||
property as filter name if this property is not set.
|
||||
|
||||
- filter.enabled:
|
||||
Boolean indicating whether the filter should be used at all or not. If it is
|
||||
not set, wireplumber will consider the filter enabled by default.
|
||||
|
||||
- filter.target:
|
||||
A JSON object that defines the matching properties of the filter's target node.
|
||||
A filter target can never be another filter node (wireplumber will ignore it),
|
||||
and must always be a device node. If this property is not set, WirePlumber will
|
||||
use the default node as target.
|
||||
|
||||
- filter.before:
|
||||
A JSON array with the filters names that are supposed to be used before this
|
||||
filter. If not set, wireplumber will link the filters by order of creation.
|
||||
|
||||
- filter.after:
|
||||
A JSON array with the filters names that are supposed to be used after this
|
||||
filter. If not set, wireplumber will link the filters by order of creation.
|
||||
|
||||
Note that these properties must be set in the filter's main node, not the
|
||||
filter's stream node.
|
||||
|
|
@ -136,6 +151,8 @@ The PipeWire configuration files for the 2 filters should be like this:
|
|||
|
||||
- /usr/share/pipewire/pipewire.conf.d/loopback-1.conf:
|
||||
|
||||
.. code-block::
|
||||
|
||||
context.modules = [
|
||||
{ name = libpipewire-module-loopback
|
||||
args = {
|
||||
|
|
@ -159,6 +176,8 @@ The PipeWire configuration files for the 2 filters should be like this:
|
|||
|
||||
- /usr/share/pipewire/pipewire.conf.d/loopback-2.conf:
|
||||
|
||||
.. code-block::
|
||||
|
||||
context.modules = [
|
||||
{ name = libpipewire-module-loopback
|
||||
args = {
|
||||
|
|
@ -183,15 +202,20 @@ Finally, if we restart PipeWire and WirePlumber to apply the configuration
|
|||
changes, and play a test.wave audio file with paplay to see if wireplumber links
|
||||
the filter nodes properly, the graph should look like this:
|
||||
|
||||
.. code-block::
|
||||
|
||||
paplay node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
paplay node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
loopback-1 stream node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
loopback-1 stream node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
|
||||
If we remove `filter.before = [ loopback-2 ]` property from the loopback-1 filter,
|
||||
|
|
@ -199,14 +223,20 @@ and add a `filter.before = [ loopback-1 ]` property in the loopback-2 filter
|
|||
configuration file. WirePlumber should link the loopback-1 filter as the last filter
|
||||
in the chain, like this:
|
||||
|
||||
paplay node -> loopback-2 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
paplay node -> loopback-2 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
loopback-1 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> loopback-1 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
.. code-block::
|
||||
|
||||
loopback-1 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
|
||||
On the other hand, the filters can have different targets. For example, we can
|
||||
|
|
@ -214,6 +244,8 @@ define the filters like this:
|
|||
|
||||
- `/usr/share/pipewire/pipewire.conf.d/loopback-1.conf`:
|
||||
|
||||
.. code-block::
|
||||
|
||||
context.modules = [
|
||||
{ name = libpipewire-module-loopback
|
||||
args = {
|
||||
|
|
@ -238,6 +270,8 @@ define the filters like this:
|
|||
|
||||
- `/usr/share/pipewire/pipewire.conf.d/loopback-2.conf`:
|
||||
|
||||
.. code-block::
|
||||
|
||||
context.modules = [
|
||||
{ name = libpipewire-module-loopback
|
||||
args = {
|
||||
|
|
@ -261,14 +295,20 @@ define the filters like this:
|
|||
If this is the case, WirePlumber will link the filters like this when using
|
||||
paplay:
|
||||
|
||||
paplay node -> loopback-2 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
paplay node -> loopback-2 main node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
loopback-1 stream node -> not-default-audio-device-name device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
.. code-block::
|
||||
|
||||
loopback-2 stream node -> default device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
.. code-block::
|
||||
|
||||
loopback-1 stream node -> not-default-audio-device-name device node
|
||||
(Stream/Output/Audio) (Audio/Sink)
|
||||
|
||||
The loopback-1 main node will only be used if an application wants to play audio
|
||||
on the device node with node name "not-default-audio-device-name".
|
||||
|
|
@ -283,10 +323,14 @@ policy at runtime.
|
|||
For example, if loopback-1 main node Id is `40`, we can disable the filter by
|
||||
setting its "filter.enabled" metadata key to false using the `pw-metadata` tool:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ pw-metadata -n filters 40 "filter.enabled" false Spa:String:JSON
|
||||
|
||||
We can also change the target of a filter at runtime:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ pw-metadata -n filters 40 "filter.target" { node.name = "new-target-node-name" } Spa:String:JSON
|
||||
|
||||
Every time a key in the filters metadata changes, all filters are unlinked and
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue