libpipewire-module-ffado-driver

title: libpipewire-module-ffado-driver(7)

summary: FFADO firewire audio driver

text:
# libpipewire-module-ffado-driver(7)

## NAME
libpipewire-module-ffado-driver - FFADO firewire audio driver

## DESCRIPTION
The ffado-driver module provides a source or sink using the libffado library for reading and writing to firewire audio devices.

## MODULE NAME
libpipewire-module-ffado-driver

## MODULE OPTIONS

- driver.mode: the driver mode, sink|source|duplex, default duplex

- ffado.devices: array of devices to open, default 'hw:0'

- ffado.period-size: period size,default 1024. A value of 0 will use the graph duration.

- ffado.period-num: period number,default 3

- ffado.sample-rate: sample-rate, default 48000. A value of 0 will use the graph rate.

- ffado.slave-mode: slave mode

- ffado.snoop-mode: snoop mode

- ffado.verbose: ffado verbose level

- ffado.rtprio: ffado realtime priority, this is by default the PipeWire server priority + 5

- ffado.realtime: ffado realtime mode. this requires correctly configured rlimits to acquire FIFO scheduling at the ffado.rtprio priority

- latency.internal.input: extra input latency in frames

- latency.internal.output: extra output latency in frames

- source.props: Extra properties for the source filter

- sink.props: Extra properties for the sink filter

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.position

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote node.name or serial.id to link to

## EXAMPLE CONFIGURATION OF A DUPLEX SINK/SOURCE

```
# ~/.config/pipewire/pipewire.conf.d/my-ffado-driver.conf
context.modules = [
{   name = libpipewire-module-ffado-driver

    args = {

        #driver.mode       = duplex

        #ffado.devices     = [ "hw:0" ]

        #ffado.period-size = 1024

        #ffado.period-num  = 3

        #ffado.sample-rate = 48000

        #ffado.slave-mode  = false

        #ffado.snoop-mode  = false

        #ffado.verbose     = 0

        #ffado.rtprio      = 65

        #ffado.realtime    = true

        #latency.internal.input  = 0

        #latency.internal.output = 0

        #audio.position    = [ FL FR ]

        source.props = {

            # extra sink properties

        }

        sink.props = {

            # extra sink properties

        }

    }
}
]
```


libpipewire-module-filter-chain

package: pipewire-libs-devel

title: libpipewire-module-filter-chain(7)

summary: Filter-Chain

text:
# libpipewire-module-filter-chain(7)

## NAME
libpipewire-module-filter-chain - Filter-Chain

## DESCRIPTION
The filter-chain allows you to create an arbitrary processing graph from LADSPA, LV2 and builtin filters. This filter can be made into a virtual sink/source or between any 2 nodes in the graph.

The filter chain is built with 2 streams, a capture stream providing the input to the filter chain and a playback stream sending out the filtered stream to the next nodes in the graph.

Because both ends of the filter-chain are built with streams, the session manager can manage the configuration and connection with the sinks and sources automatically.

## MODULE NAME
libpipewire-module-filter-chain

## MODULE OPTIONS

- node.description: a human readable name for the filter chain

- filter.graph = []: a description of the filter graph to run, see below

- capture.props = {}: properties to be passed to the input stream

- playback.props = {}: properties to be passed to the output stream

## FILTER GRAPH DESCRIPTION
The general structure of the graph description is as follows:

```
 filter.graph = {

     nodes = [

         {

             type = <ladspa | lv2 | builtin | sofa>

             name = <name>

             plugin = <plugin>

             label = <label>

             config = {

                 <configkey> = <value> ...

             }

             control = {

                 <controlname|controlindex> = <value> ...

             }

         }

         ...

     ]

     links = [

         { output = <portname> input = <portname> }

         ...

     ]

     inputs = [ <portname> ... ]

     outputs = [ <portname> ... ]

     capture.volumes = [

         { control = <portname>  min = <value>  max = <value>  scale = <scale> } ...

     ]

     playback.volumes = [

         { control = <portname>  min = <value>  max = <value>  scale = <scale> } ...

     ]
}
```

### Nodes
Nodes describe the processing filters in the graph. Use a tool like lv2ls or listplugins to get a list of available plugins, labels and the port names.

- type is one of ladspa, lv2, builtin, sofa or ebur128.

- name is the name for this node, you might need this later to refer to this node and its ports when setting controls or making links.

- plugin is the type specific plugin name.

•

For LADSPA plugins it will append .so to find the shared object with that name in the LADSPA plugin path.

•

For LV2, this is the plugin URI obtained with lv2ls.

•

For builtin, sofa and ebur128 this is ignored

•

label is the type specific filter inside the plugin.

•

For LADSPA this is the label

•

For LV2 this is unused

•

For builtin, sofa and ebur128 this is the name of the filter to use

- config contains a filter specific configuration section. Some plugins need this. (convolver, sofa, delay, ...)

- control contains the initial values for the control ports of the filter. normally these are given with the port name but it is also possible to give the control index as the key.

### Links
Links can be made between ports of nodes. The portname is given as <node_name>:<port_name>.

You can tee the output of filters to multiple other filters. You need to use a mixer if you want the output of multiple filters to go into one filter input port.

links can be omitted when the graph has just 1 filter.

### Inputs and Outputs
These are the entry and exit ports into the graph definition. Their number defines the number of channels used by the filter-chain.

The <portname> can be null when a channel is to be ignored.

Each input/output in the graph can only be linked to one filter input/output. You need to use the copy builtin filter if the stream signal needs to be routed to multiple filters. You need to use the mixer builtin plugin if multiple graph outputs need to go to one output stream.

inputs and outputs can be omitted, in which case the filter-chain will use all inputs from the first filter and all outputs from the last filter node. The graph will then be duplicated as many times to match the number of input/output channels of the streams.

### Volumes
Normally the volume of the sink/source is handled by the stream software volume. With the capture.volumes and playback.volumes properties this can be handled by a control port in the graph instead. Use capture.volumes for the volume of the input of the filter (when for example used as a sink). Use playback,volumes for the volume of the output of the filter (when for example used as a source).

The min and max values (defaults 0.0 and 1.0) respectively can be used to scale and translate the volume min and max values.

Normally the control values are linear and it is assumed that the plugin does not perform any scaling to the values. This can be changed with the scale property. By default this is linear but it can be set to cubic when the control applies a cubic transformation.

## BUILTIN FILTERS
There are some useful builtin filters available. You select them with the label of the filter node.

### Mixer
Use the mixer plugin if you have multiple input signals that need to be mixed together.

The mixer plugin has up to 8 input ports labeled 'In 1' to 'In 8' and each with a gain control labeled 'Gain 1' to 'Gain 8'. There is an output port labeled 'Out'. Unused input ports will be ignored and not cause overhead.

### Copy
Use the copy plugin if you need to copy a stream input signal to multiple filters.

It has one input port 'In' and one output port 'Out'.

### Biquads
Biquads can be used to do all kinds of filtering. They are also used when creating equalizers.

All biquad filters have an input port 'In' and an output port 'Out'. They have a 'Freq', 'Q' and 'Gain' control. Their meaning depends on the particular biquad that is used. The biquads also have 'b0', 'b1', 'b2', 'a0', 'a1' and 'a2' ports that are read-only except for the bq_raw biquad, which can configure default values depending on the graph rate and change those at runtime.

We refer to https://arachnoid.com/BiQuadDesigner/index.html for an explanation of the controls.

The following labels can be used:

- bq_lowpass a lowpass filter.

- bq_highpass a highpass filter.

- bq_bandpass a bandpass filter.

- bq_lowshelf a low shelf filter.

- bq_highshelf a high shelf filter.

- bq_peaking a peaking filter.

- bq_notch a notch filter.

- bq_allpass an allpass filter.

- bq_raw a raw biquad filter. You need a config section to specify coefficients per sample rate. The coefficients of the sample rate closest to the graph rate are selected:

```
filter.graph = {

    nodes = [

        {

            type   = builtin

            name   = ...

            label  = bq_raw

            config = {

                coefficients = [

                    { rate =  44100, b0=.., b1=.., b2=.., a0=.., a1=.., a2=.. },

                    { rate =  48000, b0=.., b1=.., b2=.., a0=.., a1=.., a2=.. },

                    { rate = 192000, b0=.., b1=.., b2=.., a0=.., a1=.., a2=.. }

                ]

            }

            ...

        }

    }

    ...
}
```

### Parametric EQ
The parametric EQ chains a number of biquads together. It is more efficient than specifying a number of chained biquads and it can also load configuration from a file.

The parametric EQ supports multichannel processing and has 8 input and 8 output ports that don't all need to be connected. The ports are named In 1 to In 8 and Out 1 to Out 8.

```
filter.graph = {

    nodes = [

        {

            type   = builtin

            name   = ...

            label  = param_eq

            config = {

                filename = "..."

                #filename1 = "...", filename2 = "...", ...

                filters = [

                    { type = ..., freq = ..., gain = ..., q = ... },

                    { type = ..., freq = ..., gain = ..., q = ... },

                    ....

                ]

                #filters1 = [ ... ], filters2 = [ ... ], ...

            }

            ...

        }

    }

    ...
}
```

Either a filename or a filters array can be specified. The configuration will be used for all channels. Alternatively filenameX or filtersX where X is the channel number (between 1 and 8) can be used to load a channel specific configuration.

The filename must point to a parametric equalizer configuration generated from the AutoEQ project or Squiglink. Both the projects allow equalizing headphones or an in-ear monitor to a target curve.

A popular example of the above being EQ'ing to the Harman target curve or EQ'ing one headphone/IEM to another.

For AutoEQ, see https://github.com/jaakkopasanen/AutoEq. For SquigLink, see https://squig.link/.

Parametric equalizer configuration generated from AutoEQ or Squiglink looks like below.

```
Preamp: -6.8 dB
Filter 1: ON PK Fc 21 Hz Gain 6.7 dB Q 1.100
Filter 2: ON PK Fc 85 Hz Gain 6.9 dB Q 3.000
Filter 3: ON PK Fc 110 Hz Gain -2.6 dB Q 2.700
Filter 4: ON PK Fc 210 Hz Gain 5.9 dB Q 2.100
Filter 5: ON PK Fc 710 Hz Gain -1.0 dB Q 0.600
Filter 6: ON PK Fc 1600 Hz Gain 2.3 dB Q 2.700
```

Fc, Gain and Q specify the frequency, gain and Q factor respectively. The fourth column can be one of PK, LSC or HSC specifying peaking, low shelf and high shelf filter respectively. More often than not only peaking filters are involved.

The filters (or channel specific filtersX where X is the channel between 1 and 8) can contain an array of filter specification object with the following keys:

type specifies the filter type, choose one from the available biquad labels. freq is the frequency passed to the biquad. gain is the gain passed to the biquad. q is the Q passed to the biquad.

This makes it possible to also use the param eq without a file and with all the available biquads.

### Convolver
The convolver can be used to apply an impulse response to a signal. It is usually used for reverbs or virtual surround. The convolver is implemented with a fast FFT implementation.

The convolver has an input port 'In' and an output port 'Out'. It requires a config section in the node declaration in this format:

```
filter.graph = {

    nodes = [

        {

            type   = builtin

            name   = ...

            label  = convolver

            config = {

                blocksize = ...

                tailsize = ...

                gain = ...

                delay = ...

                filename = ...

                offset = ...

                length = ...

                channel = ...

                resample_quality = ...

            }

            ...

        }

    }

    ...
}
```

- blocksize specifies the size of the blocks to use in the FFT. It is a value between 64 and 256. When not specified, this value is computed automatically from the number of samples in the file.

- tailsize specifies the size of the tail blocks to use in the FFT.

- gain the overall gain to apply to the IR file.

- delay The extra delay to add to the IR. A float number will be interpreted as seconds, and integer as samples. Using the delay in seconds is independent of the graph and IR rate and is recommended.

- filename The IR to load or create. Possible values are:

•

/hilbert creates a hilbert function that can be used to phase shift the signal by +/-90 degrees. The length will be used as the number of coefficients.

•

/dirac creates a Dirac function that can be used as gain.

•

A filename to load as the IR. This needs to be a file format supported by sndfile.

•

[ filename, ... ] an array of filenames. The file with the closest samplerate match with the graph samplerate will be used.

- offset The sample offset in the file as the start of the IR.

- length The number of samples to use as the IR.

- channel The channel to use from the file as the IR.

- resample_quality The resample quality in case the IR does not match the graph samplerate.

### Delay
The delay can be used to delay a signal in time.

The delay has an input port 'In' and an output port 'Out'. It also has a 'Delay (s)' control port. It requires a config section in the node declaration in this format:

```
filter.graph = {

    nodes = [

        {

            type   = builtin

            name   = ...

            label  = delay

            config = {

                "max-delay" = ...

            }

            control = {

                "Delay (s)" = ...

            }

            ...

        }

    }

    ...
}
```

•

max-delay the maximum delay in seconds. The 'Delay (s)' parameter will be clamped to this value.

### Invert
The invert plugin can be used to invert the phase of the signal.

It has an input port 'In' and an output port 'Out'.

### Clamp
The clamp plugin can be used to clamp samples between min and max values.

It has an input port 'In' and an output port 'Out'. It also has a 'Control' and 'Notify' port for the control values.

The final result is clamped to the 'Min' and 'Max' control values.

### Linear
The linear plugin can be used to apply a linear transformation on samples or control values.

It has an input port 'In' and an output port 'Out'. It also has a 'Control' and 'Notify' port for the control values.

The control value 'Mult' and 'Add' are used to configure the linear transform. Each sample or control value will be calculated as: new = old * Mult + Add.

### Reciprocal
The recip plugin can be used to calculate the reciprocal (1/x) of samples or control values.

It has an input port 'In' and an output port 'Out'. It also has a 'Control' and 'Notify' port for the control values.

### Abs
The abs plugin can be used to calculate the absolute value of samples.

It has an input port 'In' and an output port 'Out'.

### Sqrt
The sqrt plugin can be used to calculate the square root of samples.

It has an input port 'In' and an output port 'Out'.

### Exp
The exp plugin can be used to calculate the exponential (base^x) of samples or control values.

It has an input port 'In' and an output port 'Out'. It also has a 'Control' and 'Notify' port for the control values.

The control value 'Base' is used to calculate base ^ x for each sample.

### Log
The log plugin can be used to calculate the logarithm of samples or control values.

It has an input port 'In' and an output port 'Out'. It also has a 'Control' and 'Notify' port for the control values.

The control value 'Base', 'M1' and 'M2' are used to calculate out = M2 * log2f(fabsf(in * M1)) / log2f(Base) for each sample.

### Multiply
The mult plugin can be used to multiply samples together.

It has 8 input ports named 'In 1' to 'In 8' and an output port 'Out'.

All input ports samples are multiplied together into the output. Unused input ports will be ignored and not cause overhead.

### Sine
The sine plugin generates a sine wave.

It has an output port 'Out' and also a control output port 'notify'.

### Max
Use the max plugin if you need to select the max value of two channels.

It has two input ports 'In 1' and 'In 2' and one output port 'Out'.

### dcblock
Use the dcblock plugin implements a DC blocker.

It has 8 input ports 'In 1' to 'In 8' and corresponding output ports 'Out 1' to 'Out 8'. Not all ports need to be connected.

It also has 1 control input port 'R' that controls the DC block R factor.

### Ramp
Use the ramp plugin creates a linear ramp from Start to Stop.

It has 3 input control ports 'Start', 'Stop' and 'Duration (s)'. It also has one output port 'Out'. A linear ramp will be created from 'Start' to 'Stop' for a duration given by the 'Duration (s)' control in (fractional) seconds. The current value will be stored in the output notify port 'Current'.

The ramp output can, for example, be used as input for the mult plugin to create a volume ramp up or down. For more a more coarse volume ramp, the 'Current' value can be used in the linear plugin.

## SOFA FILTER
There is an optional builtin SOFA filter available.

### Spatializer
The spatializer can be used to place the sound in a 3D space.

The spatializer has an input port 'In' and a stereo pair of output ports called 'Out L' and 'Out R'. It requires a config section in the node declaration in this format:

The control can be changed at runtime to move the sounds around in the 3D space.

```
filter.graph = {

    nodes = [

        {

            type   = sofa

            name   = ...

            label  = spatializer

            config = {

                blocksize = ...

                tailsize = ...

                filename = ...

            }

            control = {

                "Azimuth" = ...

                "Elevation" = ...

                "Radius" = ...

            }

            ...

        }

    }

    ...
}
```

- blocksize specifies the size of the blocks to use in the FFT. It is a value between 64 and 256. When not specified, this value is computed automatically from the number of samples in the file.

- tailsize specifies the size of the tail blocks to use in the FFT.

- filename The SOFA file to load. SOFA files usually end in the .sofa extension and contain the HRTF for the various spatial positions.

- Azimuth controls the azimuth, this is the direction the sound is coming from in degrees between 0 and 360. 0 is straight ahead. 90 is left, 180 behind, 270 right.

- Elevation controls the elevation, this is how high/low the signal is in degrees between -90 and 90. 0 is straight in front, 90 is directly above and -90 directly below.

- Radius controls how far away the signal is as a value between 0 and 100. default is 1.0.

## EBUR128 FILTER
There is an optional EBU R128 filter available.

### ebur128
The ebur128 plugin can be used to measure the loudness of a signal.

It has 7 input ports 'In FL', 'In FR', 'In FC', 'In UNUSED', 'In SL', 'In SR' and 'In DUAL MONO', corresponding to the different input channels for EBUR128. Not all ports need to be connected for this filter.

The input signal is passed unmodified on the 'Out FL', 'Out FR', 'Out FC', 'Out UNUSED', 'Out SL', 'Out SR' and 'Out DUAL MONO' output ports.

There are 7 output control ports that contain the measured loudness information and that can be used to control the processing of the audio. Some of these ports contain values in LUFS, or 'Loudness Units relative to Full Scale'. These are negative values, closer to 0 is louder. You can use the lufs2gain plugin to convert this value to again to adjust a volume (See below).

The node also has an optional config section with extra configuration:

```
filter.graph = {

    nodes = [

        {

            type   = ebur128

            name   = ...

            label  = ebur128

            config = {

                max-history = ...

                max-window = ...

                use-histogram = ...

            }

            ...

        }

    }

    ...
}
```

- max-history the maximum history to keep in (float) seconds. Default to 10.0

- max-window the maximum window to keep in (float) seconds. Default to 0.0 You will need to set this to some value to get 'Window LUFS' output control values.

- use-histogram uses the histogram algorithm to calculate loudness. Defaults to false.

### lufs2gain
The lufs2gain plugin can be used to convert LUFS control values to gain. It needs a target LUFS control input to drive the conversion.

It has 2 input control ports 'LUFS' and 'Target LUFS' and will produce 1 output control value 'Gain'. This gain can be used as input for the builtin linear node, for example, to adust the gain.

## GENERAL OPTIONS
Options with well-known behavior. Most options can be added to the global configuration or the individual streams:

- remote.name

- audio.rate

- audio.channels

- audio.position

- media.name

- node.latency

- node.description

- node.group

- node.link.group

- node.virtual

- node.name : See notes below. If not specified, defaults to 'filter-chain-PID-MODULEID'.

Stream only properties:

- media.class

- node.name : if not given per stream, the global node.name will be prefixed with 'input.' and 'output.' to generate a capture and playback stream node.name respectively.

## EXAMPLE CONFIGURATION OF A VIRTUAL SOURCE
This example uses the rnnoise LADSPA plugin to create a new virtual source.

Run with pipewire -c filter-chain.conf. The configuration can also be put under pipewire.conf.d/ to run it inside the PipeWire server.

```
# ~/.config/pipewire/filter-chain.conf.d/my-filter-chain-1.conf
context.modules = [
{   name = libpipewire-module-filter-chain

    args = {

        node.description =  "Noise Canceling source"

        media.name =  "Noise Canceling source"

        filter.graph = {

            nodes = [

                {

                    type = ladspa

                    name = rnnoise

                    plugin = ladspa/librnnoise_ladspa

                    label = noise_suppressor_stereo

                    control = {

                        "VAD Threshold (%)" 50.0

                    }

                }

            ]

        }

        capture.props = {

            node.name =  "capture.rnnoise_source"

            node.passive = true

        }

        playback.props = {

            node.name =  "rnnoise_source"

            media.class = Audio/Source

        }

    }
}
]
```

## EXAMPLE CONFIGURATION OF A DOLBY SURROUND ENCODER VIRTUAL SINK
This example uses the ladpsa surround encoder to encode a 5.1 signal to a stereo Dolby Surround signal.

```
# ~/.config/pipewire/filter-chain.conf.d/my-filter-chain-2.conf
context.modules = [
{   name = libpipewire-module-filter-chain

    args = {

        node.description = "Dolby Surround Sink"

        media.name       = "Dolby Surround Sink"

        filter.graph = {

            nodes = [

                {

                    type  = builtin

                    name  = mixer

                    label = mixer

                    control = { "Gain 1" = 0.5 "Gain 2" = 0.5 }

                }

                {

                    type   = ladspa

                    name   = enc

                    plugin = surround_encoder_1401

                    label  = surroundEncoder

                }

            ]

            links = [

                { output = "mixer:Out" input = "enc:S" }

            ]

            inputs  = [ "enc:L" "enc:R" "enc:C" null "mixer:In 1" "mixer:In 2" ]

            outputs = [ "enc:Lt" "enc:Rt" ]

        }

        capture.props = {

            node.name      = "effect_input.dolby_surround"

            media.class    = Audio/Sink

            audio.channels = 6

            audio.position = [ FL FR FC LFE SL SR ]

        }

        playback.props = {

            node.name      = "effect_output.dolby_surround"

            node.passive   = true

            audio.channels = 2

            audio.position = [ FL FR ]

        }

    }
}
]
```


libpipewire-module-jack-tunnel

title: libpipewire-module-jack-tunnel(7)

summary: JACK Tunnel

text:
# libpipewire-module-jack-tunnel(7)

## NAME
libpipewire-module-jack-tunnel - JACK Tunnel

## DESCRIPTION
The jack-tunnel module provides a source or sink that tunnels all audio to a JACK server.

This module is usually used together with JACK DBus detect that will automatically load the tunnel with the right parameters based on dbus information.

## MODULE NAME
libpipewire-module-jack-tunnel

## MODULE OPTIONS

- jack.library: the libjack to load, by default libjack.so.0 is searched in JACK_PATH directories and then some standard library paths. Can be an absolute path.

- jack.server: the name of the JACK server to tunnel to.

- jack.client-name: the name of the JACK client.

- jack.connect: if jack ports should be connected automatically. Can also be placed per stream.

- tunnel.mode: the tunnel mode, sink|source|duplex, default duplex

- midi.ports: the number of midi ports. Can also be added to the stream props.

- source.props: Extra properties for the source filter.

- sink.props: Extra properties for the sink filter.

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.channels

- audio.position

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote node.name or serial.id to link to

## EXAMPLE CONFIGURATION OF A DUPLEX SINK/SOURCE

```
# ~/.config/pipewire/pipewire.conf.d/my-jack-tunnel.conf
context.modules = [
{   name = libpipewire-module-jack-tunnel

    args = {

        #jack.library     = libjack.so.0

        #jack.server      = null

        #jack.client-name = PipeWire

        #jack.connect     = true

        #tunnel.mode      = duplex

        #midi.ports       = 0

        #audio.channels   = 2

        #audio.position   = [ FL FR ]

        source.props = {

            # extra sink properties

        }

        sink.props = {

            # extra sink properties

        }

    }
}
]
```


libpipewire-module-jackdbus-detect

title: libpipewire-module-jackdbus-detect(7)

summary: JACK DBus detect

text:
# libpipewire-module-jackdbus-detect(7)

## NAME
libpipewire-module-jackdbus-detect - JACK DBus detect

## DESCRIPTION
Automatically creates a sink/source when a jackdbus server is started and connect to JACK.

## MODULE NAME
libpipewire-module-jackdbus-detect

## MODULE OPTIONS
There are no module-specific options, all arguments are passed to JACK Tunnel.

## CONFIG OVERRIDE
A module.jackdbus-detect.args config section can be added to override the module arguments.

```
# ~/.config/pipewire/pipewire.conf.d/my-jack-dbus-detect-args.conf
module.jackdbus-detect.args = {

    #tunnel.mode    = duplex
}
```

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-jack-dbus-detect.conf
context.modules = [

 {   name = libpipewire-module-jackdbus-detect

     args {

        #jack.server    = null

        #tunnel.mode    = duplex

        #audio.channels = 2

        #audio.position = [ FL FR ]

        source.props = {

            # extra sink properties

        }

        sink.props = {

            # extra sink properties

        }

     }

 }
]
```


libpipewire-module-link-factory

title: libpipewire-module-link-factory(7)

summary: Link Factory

text:
# libpipewire-module-link-factory(7)

## NAME
libpipewire-module-link-factory - Link Factory

## DESCRIPTION
Allows clients to create links between ports.

This module creates a new factory. Clients that can see the factory can use the factory name (link-factory) to create new link objects with pw_core_create_object(). It is also possible to create objects in the config file.

Object of the PW_TYPE_INTERFACE_Link will be created and a proxy to it will be returned.

As an argument to the create_object call, a set of properties will control what ports will be linked.

## MODULE NAME
libpipewire-module-link-factory

## MODULE OPTIONS
•

allow.link.passive: if the link.passive property is allowed. Default false. By default, the core will decide when a link is passive based on the properties of the node and ports.

## PROPERTIES FOR THE CREATE_OBJECT CALL

- link.output.node: The output node to use. This can be the node object.id, node.name, node.nick, node.description or object.path of a node. When the property is not given or NULL, the output port should be specified.

- link.output.port: The output port to link. This can be a port object.id, port.name, port.alias or object.path. If an output node is specified, the port must belong to the node. Finding a port in a node using the port.id is deprecated and may lead to unexpected results when the port.id also matches an object.id. If no output port is given, an output node must be specified and a random (unlinked) port will be used from the node.

- link.input.node: The input node to use. This can be the node object.id, node.name, node.nick, node.description or object.path of a node. When the property is not given or NULL, the input port should be specified.

- link.input.port: The input port to link. This can be a port object.id, port.name, port.alias or object.path. If an input node is specified, the port must belong to the node. Finding a port in a node using the port.id is deprecated and may lead to unexpected results when the port.id also matches an object.id. If no input port is given, an input node must be specified and a random (unlinked) port will be used from the node.

- object.linger: Keep the link around even when the client that created it is gone.

- link.passive: The link is passive, meaning that it will not keep nodes busy. By default this property is ignored and the node and port properties are used to determine the passive state of the link.

## EXAMPLE CONFIGURATION
The module is usually added to the config file of the main pipewire daemon.

```
context.modules = [
{ name = libpipewire-link-factory

  args = {

      #allow.link.passive = false

  }
}
]
```

## CONFIG OVERRIDE
A module.link-factory.args config section can be added to override the module arguments.

```
# ~/.config/pipewire/pipewire.conf.d/my-link-factory-args.conf
module.link-factory.args = {

    #allow.link.passive = false
}
```

## CONFIG OBJECTS
To create an object from the factory, one can use the pw_core_create_object() method or make an object in the context.objects section like:

```
context.objects = [
{ factory = link-factory

    args = {

        link.output.node = system

        link.output.port = capture_2

        link.input.node  = my-mic

        link.input.port  = input_FR

    }
}
```

Note that this only works when the ports that need to be linked are available at the time the config file is parsed.

## SEE ALSO
•

pw-link: a tool to manage port links


libpipewire-module-loopback

title: libpipewire-module-loopback(7)

summary: Loopback

text:
# libpipewire-module-loopback(7)

## NAME
libpipewire-module-loopback - Loopback

## DESCRIPTION
The loopback module passes the output of a capture stream unmodified to a playback stream. It can be used to construct a link between a source and sink but also to create new virtual sinks or sources or to remap channel between streams.

Because both ends of the loopback are built with streams, the session manager can manage the configuration and connection with the sinks and sources.

## MODULE NAME
libpipewire-module-loopback

## MODULE OPTIONS

- node.description: a human readable name for the loopback streams

- target.delay.sec: delay in seconds as float (Since 0.3.60)

- capture.props = {}: properties to be passed to the input stream

- playback.props = {}: properties to be passed to the output stream

## GENERAL OPTIONS
Options with well-known behavior. Most options can be added to the global configuration or the individual streams:

- remote.name

- audio.rate

- audio.channels

- audio.position

- media.name

- node.latency

- node.description

- node.group

- node.link.group

- node.virtual

- node.name : See notes below. If not specified, defaults to 'loopback-PID-MODULEID'.

Stream only properties:

- media.class

- node.name : if not given per stream, the global node.name will be prefixed with 'input.' and 'output.' to generate a capture and playback stream node.name respectively.

## CHANNEL HANDLING
Channels from the capture stream are copied, in order, to the channels of the output stream. The remaining streams are ignored (when capture has more channels) or filled with silence (when playback has more channels).

When a global channel position is set, both capture and playback will be converted to and from this common channel layout. This can be used to implement up or downmixing loopback sinks/sources.

## EXAMPLE CONFIGURATION OF SOURCE TO SINK LINK
This loopback links a source node to a sink node. You can change the target.object properties to match your source/sink node.name.

```
# ~/.config/pipewire/pipewire.conf.d/my-loopback-0.conf
context.modules = [
{   name = libpipewire-module-loopback

    args = {

        capture.props = {

            #  if you want to capture sink monitor ports,

            #  uncomment the next line and set the target.object

            #  to the sink name.

            #stream.capture.sink = true

            target.object = "alsa_input.usb-C-Media_Electronics_Inc._TONOR_TC-777_Audio_Device-00.mono-fallback"

            node.passive = true

            node.dont-reconnect = true

        }

        playback.props = {

            target.object = "alsa_output.usb-0d8c_USB_Sound_Device-00.analog-surround-71"

            node.dont-reconnect = true

            node.passive = true

        }

    }
}
]
```

## EXAMPLE CONFIGURATION OF A VIRTUAL SINK
This Virtual sink routes stereo input to the rear channels of a 7.1 sink.

```
# ~/.config/pipewire/pipewire.conf.d/my-loopback-1.conf
context.modules = [
{   name = libpipewire-module-loopback

    args = {

        node.description = "CM106 Stereo Pair 2"

        #target.delay.sec = 1.5

        capture.props = {

            node.name = "CM106_stereo_pair_2"

            media.class = "Audio/Sink"

            audio.position = [ FL FR ]

        }

        playback.props = {

            node.name = "playback.CM106_stereo_pair_2"

            audio.position = [ RL RR ]

            target.object = "alsa_output.usb-0d8c_USB_Sound_Device-00.analog-surround-71"

            node.dont-reconnect = true

            stream.dont-remix = true

            node.passive = true

        }

    }
}
]
```

## EXAMPLE CONFIGURATION OF A VIRTUAL SOURCE
This Virtual source routes the front-left channel of a multi-channel input to a mono channel. This is useful for splitting up multi-channel inputs from USB audio interfaces that are not yet fully supported by alsa.

```
# ~/.config/pipewire/pipewire.conf.d/my-loopback-2.conf
context.modules = [
{   name = libpipewire-module-loopback

    args = {

        node.description = "Scarlett Focusrite Line 1"

        capture.props = {

            audio.position = [ FL ]

            stream.dont-remix = true

            node.target = "alsa_input.usb-Focusrite_Scarlett_Solo_USB_Y7ZD17C24495BC-00.analog-stereo"

            node.passive = true

        }

        playback.props = {

            node.name = "SF_mono_in_1"

            media.class = "Audio/Source"

            audio.position = [ MONO ]

        }

    }
}
]
```

## EXAMPLE CONFIGURATION OF AN UPMIX SINK
This Virtual sink has 2 input channels and 6 output channels. It will perform upmixing using the PSD algorithm on the playback stream.

```
# ~/.config/pipewire/pipewire.conf.d/my-loopback-3.conf
context.modules = [
{   name = libpipewire-module-loopback

    args = {

        node.description = "Upmix Sink"

        audio.position = [ FL FR ]

        capture.props = {

            node.name = "effect_input.upmix"

            media.class = Audio/Sink

        }

        playback.props = {

            node.name = "effect_output.upmix"

            audio.position = [ FL FR RL RR FC LFE ]

            node.passive = true

            stream.dont-remix = true

            channelmix.upmix = true

            channelmix.upmix-method = psd

            channelmix.lfe-cutoff = 150

            channelmix.fc-cutoff = 12000

            channelmix.rear-delay = 12.0

        }

    }
}
]
```

## EXAMPLE CONFIGURATION OF A DOWNMIX SOURCE
This Virtual source has 2 input channels and a mono output channel. It will perform downmixing from the two first AUX channels of a pro-audio device.

```
# ~/.config/pipewire/pipewire.conf.d/my-loopback-4.conf
context.modules = [
{   name = libpipewire-module-loopback

    args = {

        node.description = "Downmix Source"

        audio.position = [ AUX0 AUX1 ]

        capture.props = {

            node.name = "effect_input.downmix"

            target.object = "alsa_input.usb-BEHRINGER_UMC404HD_192k-00.pro-input-0"

            node.passive = true

            stream.dont-remix = true

        }

        playback.props = {

            node.name = "effect_output.downmix"

            media.class = Audio/Source

            audio.position = [ MONO ]

        }

    }
}
]
```

## SEE ALSO
pw-loopback : a tool that loads the loopback module with given parameters.


libpipewire-module-metadata

title: libpipewire-module-metadata(7)

summary: Metadata

text:
# libpipewire-module-metadata(7)

## NAME
libpipewire-module-metadata - Metadata

## DESCRIPTION
Allows clients to export a metadata store to the PipeWire server.

Both the client and the server need to load this module for the metadata to be exported.

This module creates a new factory and a new export type for the PW_TYPE_INTERFACE_Metadata interface.

A client will first create an implementation of the PW_TYPE_INTERFACE_Metadata interface with pw_context_create_metadata(), for example. With the pw_core_export(), this module will create a server side resource to expose the metadata implementation to other clients. Modifications done by the client on the local metadata interface will be visible to all PipeWire clients.

It is also possible to use the factory to create metadata in the current processes using a config file fragment.

As an argument to the create_object call, a set of properties will control the name of the metadata and some initial values.

## MODULE NAME
libpipewire-module-metadata

## MODULE OPTIONS
This module has no options.

## PROPERTIES FOR THE CREATE_OBJECT CALL

- metadata.name: The name of the new metadata object. If not given, the metadata object name will be default.

- metadata.values: A JSON array of objects with initial values for the metadata object.

the metadata.values key has the following layout:

```
metadata.values = [

   { id = <int>  key = <key>  type = <type> value = <object> }

   ....
]
```

•

id: an optional object id for the metadata, default 0

•

key: a string, the metadata key

•

type: an optional metadata value type

•

value: a JSON item, the metadata value.

## EXAMPLE CONFIGURATION
The module is usually added to the config file of the main PipeWire daemon and the clients.

```
context.modules = [
{ name = libpipewire-module-metadata }
]
```

## CONFIG OBJECTS
To create an object from the factory, one can use the pw_core_create_object() method or make an object in the context.objects section like in the main PipeWire daemon config file:

```
context.objects = [
{ factory = metadata

    args = {

        metadata.name = default

        metadata.values = [

           { key = default.audio.sink   value = { name = somesink } }

           { key = default.audio.source value = { name = somesource } }

        ]

    }
}
```

This creates a new default metadata store with 2 key/values.

## SEE ALSO
•

pw-metadata: a tool to manage metadata


title: libpipewire-module-netjack2-driver(7)

summary: Netjack2 driver

text:
# libpipewire-module-netjack2-driver(7)

## NAME
libpipewire-module-netjack2-driver - Netjack2 driver

## DESCRIPTION
The netjack2-driver module provides a source or sink that is following a netjack2 manager. It is meant to be used over stable (ethernet) network connections with minimal latency and jitter.

The driver normally decides how many ports it will send and receive from the manager. By default however, these values are set to -1 so that the manager decides on the number of ports.

With the global or per stream audio.port and midi.ports properties this behaviour can be adjusted.

The driver will send out UDP messages on a (typically) multicast address to inform the manager of the available driver. This will then instruct the manager to configure and start the driver.

On the driver side, a sink and/or source with the specified numner of audio and midi ports will be created. On the manager side there will be a corresponding source and/or sink created respectively.

The driver will be scheduled with exactly the same period as the manager but with a configurable number of periods of delay (see netjack2.latency, default 2).

## MODULE NAME
libpipewire-module-netjack2-driver

## MODULE OPTIONS

- driver.mode: the driver mode, sink|source|duplex, default duplex. This set the per stream audio.port and midi.ports default from -1 to 0. sink mode defaults to no source ports, source mode to no sink ports and duplex leaves the defaults as they are.

- local.ifname = <str>: interface name to use

- net.ip =<str>: multicast IP address, default '225.3.19.154'

- net.port =<int>: control port, default 19000

- net.mtu = <int>: MTU to use, default 1500

- net.ttl = <int>: TTL to use, default 1

- net.loop = <bool>: loopback multicast, default false

- source.ip =<str>: IP address to bind to, default '0.0.0.0'

- source.port =<int>: port to bind to, default 0 (allocate)

- netjack2.client-name: the name of the NETJACK2 client.

- netjack2.latency: the latency in cycles, default 2

- audio.ports: the number of audio ports. Can also be added to the stream props. A value of -1 will configure to the number of audio ports on the manager.

- midi.ports: the number of midi ports. Can also be added to the stream props. A value of -1 will configure to the number of midi ports on the manager.

- source.props: Extra properties for the source filter.

- sink.props: Extra properties for the sink filter.

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.channels

- audio.position

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote node.name or serial.id to link to

## EXAMPLE CONFIGURATION OF A DUPLEX SINK/SOURCE

```
# ~/.config/pipewire/pipewire.conf.d/my-netjack2-driver.conf
context.modules = [
{   name = libpipewire-module-netjack2-driver

    args = {

        #netjack2.client-name = PipeWire

        #netjack2.latency     = 2

        #midi.ports           = 0

        #audio.ports          = -1

        #audio.channels       = 2

        #audio.position       = [ FL FR ]

        source.props = {

            # extra source properties

        }

        sink.props = {

            # extra sink properties

        }

    }
}
]
```


title: libpipewire-module-netjack2-manager(7)

summary: Netjack2 manager

text:
# libpipewire-module-netjack2-manager(7)

## NAME
libpipewire-module-netjack2-manager - Netjack2 manager

## DESCRIPTION
The netjack2 manager module listens for new netjack2 driver messages and will start a communication channel with them.

Messages are received on a (typically) multicast address.

Normally, the driver will specify the number of send and receive channels it wants to set up with the manager. If the driver however specifies a don't-care value of -1, the audio.ports and midi.ports configuration values of the manager are used.

The manager will create the corresponding streams to send and receive data to/from the drivers. These are usually sink and sources but with the netjack2.connect property, these will be streams that will be autoconnected to the default source and sink by the session manager.

## MODULE NAME
libpipewire-module-netjack2-manager

## MODULE OPTIONS

- local.ifname = <str>: interface name to use

- net.ip =<str>: multicast IP address, default '225.3.19.154'

- net.port =<int>: control port, default '19000'

- net.mtu = <int>: MTU to use, default 1500

- net.ttl = <int>: TTL to use, default 1

- net.loop = <bool>: loopback multicast, default false

- netjack2.connect: if jack ports should be connected automatically. Can also be placed per stream, default false.

- netjack2.sample-rate: the sample rate to use, default 48000

- netjack2.period-size: the buffer size to use, default 1024

- netjack2.encoding: the encoding, float|opus|int, default float

- netjack2.kbps: the number of kilobits per second when encoding, default 64

- audio.ports: the number of audio ports. Can also be added to the stream props. This is the default suggestion for drivers that don't specify any number of audio channels.

- midi.ports: the number of midi ports. Can also be added to the stream props. This is the default suggestion for drivers that don't specify any number of midi channels.

- audio.position: default channel position for the number of audio.ports.

- source.props: Extra properties for the source filter.

- sink.props: Extra properties for the sink filter.

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.channels

- audio.position

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote node.name or serial.id to link to

## EXAMPLE CONFIGURATION OF A DUPLEX SINK/SOURCE

```
# ~/.config/pipewire/pipewire.conf.d/my-netjack2-manager.conf
context.modules = [
{   name = libpipewire-module-netjack2-manager

    args = {

        #netjack2.connect     = true

        #netjack2.sample-rate = 48000

        #netjack2.period-size = 1024

        #netjack2.encoding    = float # float|opus

        #netjack2.kbps        = 64

        #audio.ports          = 0

        #midi.ports           = 0

        #audio.channels       = 2

        #audio.position       = [ FL FR ]

        source.props = {

            # extra source properties

        }

        sink.props = {

            # extra sink properties

        }

    }
}
]
```


libpipewire-module-parametric-equalizer

summary: Parametric-Equalizer

text:
# libpipewire-module-parametric-equalizer(7)

## NAME
libpipewire-module-parametric-equalizer - Parametric-Equalizer

## DESCRIPTION
The parametric-equalizer module loads parametric equalizer configuration generated from the AutoEQ project or Squiglink. Both the projects allow equalizing headphones or an in-ear monitor to a target curve. While these generate a file for parametric equalization for a given target, but this is not a format that can be directly given to filter chain module.

A popular example of the above being EQ'ing to the Harman target curve or EQ'ing one headphone/IEM to another.

For AutoEQ, see https://github.com/jaakkopasanen/AutoEq. For SquigLink, see https://squig.link/.

Parametric equalizer configuration generated from AutoEQ or Squiglink looks like below.

```
Preamp: -6.8 dB
Filter 1: ON PK Fc 21 Hz Gain 6.7 dB Q 1.100
Filter 2: ON PK Fc 85 Hz Gain 6.9 dB Q 3.000
Filter 3: ON PK Fc 110 Hz Gain -2.6 dB Q 2.700
Filter 4: ON PK Fc 210 Hz Gain 5.9 dB Q 2.100
Filter 5: ON PK Fc 710 Hz Gain -1.0 dB Q 0.600
Filter 6: ON PK Fc 1600 Hz Gain 2.3 dB Q 2.700
```

Fc, Gain and Q specify the frequency, gain and Q factor respectively. The fourth column can be one of PK, LSC or HSC specifying peaking, low shelf and high shelf filter respectively. More often than not only peaking filters are involved.

This module parses a configuration like above and loads the filter chain module with the above configuration translated to filter chain arguments.

## MODULE NAME
libpipewire-module-parametric-equalizer

## MODULE OPTIONS
Options specific to the behaviour of this module

- equalizer.filepath = <str> path of the file with parametric EQ

- equalizer.description = <str>: Name which will show up in

- audio.channels = <int>: Number of audio channels, default 2

- audio.position = <str>: Channel map, default '[FL, FR]'

- remote.name = <str>: environment with remote name, default 'pipewire-0'

- capture.props = {}: properties passed to the input stream, default { media.class = 'Audio/Sink', node.name = 'effect_input.eq<number of nodes>' }

- playback.props = {}: properties passed to the output stream, default { node.passive = true, node.name = 'effect_output.eq<number of nodes>' }

## GENERAL OPTIONS
Options with well-known behaviour:

- audio.channels

- audio.position

- remote.name

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-parametric-equalizer.conf
context.modules = [
{   name = libpipewire-module-parametric-equalizer

    args = {

        #remote.name = "pipewire-0"

        #equalizer.filepath = "/a/b/EQ.txt"

        #equalizer.description = "Parametric EQ Sink"

        #audio.channels = 2

        #audio.position = [FL, FR]

        #capture.props = {

        #  node.name = "Parametric EQ input"

        #}

        #playback.props = {

        #  node.name = "Parametric EQ output"

        #}

    }
}
]
```

Since

1.0.6


libpipewire-module-pipe-tunnel

title: libpipewire-module-pipe-tunnel(7)

summary: Unix Pipe Tunnel

text:
# libpipewire-module-pipe-tunnel(7)

## NAME
libpipewire-module-pipe-tunnel - Unix Pipe Tunnel

## DESCRIPTION
The pipe-tunnel module provides a source or sink that tunnels all audio to or from a unix pipe respectively.

## MODULE NAME
libpipewire-module-pipe-tunnel

## MODULE OPTIONS

- tunnel.mode: the desired tunnel to create. (Default playback)

- tunnel.may-pause: if the tunnel stream is allowed to pause on xrun

- pipe.filename: the filename of the pipe.

- stream.props: Extra properties for the local stream.

When tunnel.mode is capture, a capture stream on the default source is created. The samples captured from the source will be written to the pipe.

When tunnel.mode is sink, a sink node is created. Samples played on the sink will be written to the pipe.

When tunnel.mode is playback, a playback stream on the default sink is created. The samples read from the pipe will be played on the sink.

When tunnel.mode is source, a source node is created. Samples read from the the pipe will be made available on the source.

tunnel.may-pause allows the tunnel stream to become inactive (paused) when there is no data in the fifo or when the fifo is full. For capture and playback tunnel.mode this is by default true. For source and sink tunnel.mode, this is by default false. A paused stream will consume no CPU and will resume when the fifo becomes readable or writable again.

When pipe.filename is not given, a default fifo in /tmp/fifo_input or /tmp/fifo_output will be created that can be written and read respectively, depending on the selected tunnel.mode.

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- node.latency

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote name or serial id to link to

When not otherwise specified, the pipe will accept or produce a 16 bits, stereo, 48KHz sample stream.

## EXAMPLE CONFIGURATION OF A PIPE PLAYBACK STREAM

```
# ~/.config/pipewire/pipewire.conf.d/my-pipe-tunnel.conf
context.modules = [
{   name = libpipewire-module-pipe-tunnel

    args = {

        tunnel.mode = playback

        #tunnel.may-pause = true

        # Set the pipe name to tunnel to

        pipe.filename = "/tmp/fifo_output"

        #audio.format=<sample format>

        #audio.rate=<sample rate>

        #audio.channels=<number of channels>

        #audio.position=<channel map>

        #target.object=<remote target node>

        stream.props = {

            # extra sink properties

        }

    }
}
]
```


libpipewire-module-portal

title: libpipewire-module-portal(7)

summary: Portal

text:
# libpipewire-module-portal(7)

## NAME
libpipewire-module-portal - Portal

## DESCRIPTION
The portal module performs access control management for clients started inside an XDG portal.

The module connects to the session DBus and subscribes to NameOwnerChanged signals for the org.freedesktop.portal.Desktop name. The PID of the DBus name owner is the portal.

A client connection from the portal PID to PipeWire gets assigned a pipewire.access of 'portal' and set to permissions ALL - it is the responsibility of the portal to limit the permissions before passing the connection on to the client. See Access Control for details on permissions.

Clients connecting from other PIDs are ignored by this module.

## MODULE NAME
libpipewire-module-portal

## MODULE OPTIONS
There are no module-specific options.

## GENERAL OPTIONS
There are no general options for this module.

## EXAMPLE CONFIGURATION

```
context.modules = [

 {   name = libpipewire-module-portal }
]
```


libpipewire-module-profiler

title: libpipewire-module-profiler(7)

summary: Profiler

text:
# libpipewire-module-profiler(7)

## NAME
libpipewire-module-profiler - Profiler

## DESCRIPTION
The profiler module provides a Profiler interface for applications that can be used to receive profiling information.

Use tools like pw-top and pw-profiler to collect profiling information about the pipewire graph.

## MODULE NAME
libpipewire-module-profiler

## MODULE OPTIONS
•

profile.interval.ms: Can be used to avoid gathering profiling information on every processing cycle. This allows trading off CPU usage for profiling accuracy. Default 0

## CONFIG OVERRIDE
A module.profiler.args config section can be added to override the module arguments.

```
# ~/.config/pipewire/pipewire.conf.d/my-profiler-args.conf
module.profiler.args = {

    #profile.interval.ms = 10
}
```

## EXAMPLE CONFIGURATION
The module is usually added to the config file of the main pipewire daemon.

```
context.modules = [
{ name = libpipewire-module-profiler

  args = {

      #profile.interval.ms = 0

  }
}
]
```

## SEE ALSO

- pw-top: a tool to display realtime profiler data

- pw-profiler: a tool to collect and render profiler data


libpipewire-module-protocol-native

title: libpipewire-module-protocol-native(7)

summary: Protocol Native

text:
# libpipewire-module-protocol-native(7)

## NAME
libpipewire-module-protocol-native - Protocol Native

## DESCRIPTION
The native protocol module implements the PipeWire communication between a client and a server using unix local sockets.

Normally this module is loaded in both client and server config files so that they can communicate.

## MODULE NAME
libpipewire-module-protocol-native

## MODULE OPTIONS
The module supports the following arguments:

•

sockets: [ { name = 'socket-name', owner = 'owner', group = 'group', mode = 'mode', selinux.context = 'context' }, props = { ... }, ... ]

Array of Unix socket names and (optionally) owner/permissions to serve, if the context is a server. If not absolute paths, the sockets are created in the default runtime directory.

The props are copied directly to any client that connects through this server socket and can be used to configure special permissions.

Has the default value [ { name = 'CORENAME' }, { name = 'CORENAME-manager' } ], where CORENAME is the name of the PipeWire core, usually pipewire-0.

The permissions have no effect for sockets from Systemd socket activation. Those should be configured via the systemd.socket(5) mechanism.

## GENERAL OPTIONS
The name of the core is obtained as:

- PIPEWIRE_CORE : the environment variable with the name of the core

- core.name : in the context properties

- a name based on the process id

The context will also become a server if:

- PIPEWIRE_DAEMON : the environment is true

- core.daemon : in the context properties is true

The socket will be located in the directory obtained by looking at the following environment variables:

- PIPEWIRE_RUNTIME_DIR

- XDG_RUNTIME_DIR

- USERPROFILE

The socket address will be written into the notification file descriptor if the following environment variable is set:

•

PIPEWIRE_NOTIFICATION_FD

When a client connect, the connection will be made to:

- PIPEWIRE_REMOTE : the environment with the remote name

- remote.name : the property in the context.

- The default remote named 'pipewire-0'

A Special remote named 'internal' can be used to make a connection to the local context. This can be done even when the server is not a daemon. It can be used to treat a local context as if it was a server.

## CONFIG OVERRIDE
A module.protocol-native.args config section can be added to override the module arguments.

```
# ~/.config/pipewire/pipewire.conf.d/my-protocol-native-args.conf
module.protocol-native.args = {

       sockets = [

           { name = "pipewire-0" }

           { name = "pipewire-0-manager" }

       ]
}
```

## EXAMPLE CONFIGURATION

```
context.modules = [
{ name = libpipewire-module-protocol-native }
]
```

```
context.modules = [

 { name = libpipewire-module-protocol-native,

   args = {

       sockets = [

           { name = "pipewire-0" }

           { name = "pipewire-0-manager" }

           { name = "pipewire-1"

             props = { my.connection = "the other one" }

           }

       ]

   }

 }
]
```


libpipewire-module-protocol-pulse

title: libpipewire-module-protocol-pulse(7)

summary: Protocol Pulse

text:
# libpipewire-module-protocol-pulse(7)

## NAME
libpipewire-module-protocol-pulse - Protocol Pulse

## DESCRIPTION
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.

## MODULE NAME
libpipewire-module-protocol-pulse

## MODULE OPTIONS
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.

## PULSE.PROPERTIES
A config section with server properties can be given.

```
# ~/.config/pipewire/pipewire-pulse.conf.d/custom.conf
pulse.properties = {

    # the addresses this server listens on

    server.address = [

        "unix:native"

        #"unix:/tmp/something"              # absolute paths may be used

        #"tcp:4713"                         # IPv4 and IPv6 on all addresses

        #"tcp:[::]:9999"                    # IPv6 on all addresses

        #"tcp:127.0.0.1:8888"               # IPv4 on a single address

        #

        #{ address = "tcp:4713"             # address

        #  max-clients = 64                 # maximum number of clients

        #  listen-backlog = 32              # backlog in the server listen queue

        #  client.access = "restricted"     # permissions for clients

        #}

    ]

    #server.dbus-name       = "org.pulseaudio.Server"

    #pulse.allow-module-loading = true

    #pulse.min.req          = 128/48000     # 2.7ms

    #pulse.default.req      = 960/48000     # 20 milliseconds

    #pulse.min.frag         = 128/48000     # 2.7ms

    #pulse.default.frag     = 96000/48000   # 2 seconds

    #pulse.default.tlength  = 96000/48000   # 2 seconds

    #pulse.min.quantum      = 128/48000     # 2.7ms

    #pulse.default.format   = F32

    #pulse.default.position = [ FL FR ]

    #pulse.idle.timeout     = 0
}
pulse.properties.rules = [

    {   matches = [ { cpu.vm.name = !null } ]

        actions = {

            update-props = {

                # These overrides are only applied when running in a vm.

                pulse.min.quantum = 1024/48000      # 22ms

            }

        }

    }
]
```

### Connection options

```
...
server.address = [

    "unix:native"

    # "tcp:4713"
]
...
```

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:

```
....
server.address = [

  {  address = "tcp:4713"             # address

     max-clients = 64                 # maximum number of clients

     listen-backlog = 32              # backlog in the server listen queue

     client.access = "restricted"     # permissions for clients

  }
....
```

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).

```
server.dbus-name       = "org.pulseaudio.Server"
```

The DBus name to reserve for the server. If you have multiple servers, you might want to change the name.

```
pulse.allow-module-loading = true
```

By default, clients are allowed to load and unload modules. You can disable this feature with this option.

### Playback buffering options

```
pulse.min.req = 128/48000              # 2.7ms
```

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.

```
pulse.default.req = 960/48000          # 20 milliseconds
```

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.

```
pulse.default.tlength = 96000/48000    # 2 seconds
```

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.

### Record buffering options

```
pulse.min.frag = 128/48000             # 2.7ms
```

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.

```
pulse.default.frag = 96000/48000       # 2 seconds
```

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.

### Scheduling options

```
pulse.min.quantum = 128/48000          # 2.7ms
```

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.

### Format options

```
pulse.default.format = F32
```

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.

```
pulse.default.position = [ FL FR ]
```

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.

### Quirk options

```
pulse.fix.format = "S16LE"
```

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.

```
pulse.fix.rate = 48000
```

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.

```
pulse.fix.position = "[ FL FR ]"
```

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.

```
pulse.idle.timeout = 0
```

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.

## COMMAND EXECUTION
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.

```
# Extra commands can be executed here.
#   load-module : loads a module with args and flags
#      args = "<module-name> <module-args>"
#      ( flags = [ "no-fail" ] )
#      ( condition = [ { <key1> = <value1>, ... } ... ] )
# conditions will check the pulse.properties key/values.
pulse.cmd = [

    { cmd = "load-module" args = "module-always-sink" flags = [ ] }

    #{ cmd = "load-module" args = "module-switch-on-connect" condition = [ { pulse.cmd.switch-on-connect = true } ]

    #{ cmd = "load-module" args = "module-gsettings" flags = [ "nofail" ] }
]
```

## DYNAMIC PROPERTIES
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.

```
pulse.properties.rules = [

    {   matches = [ { cpu.vm.name = !null } ]

        actions = {

            update-props = {

                # These overrides are only applied when running in a vm.

                pulse.min.quantum = 1024/48000      # 22ms

            }

        }

    }
]
```

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.

## STREAM SETTINGS AND RULES
Streams created by module-protocol-pulse will use the stream.properties section and stream.rules sections as usual.

## APPLICATION SETTINGS (RULES)
The pulse protocol module supports generic config rules. It supports a pulse.rules section with a quirks and an update-props action. These rules operate on the client properties (not the stream properties, see above).

```
# ~/.config/pipewire/pipewire-pulse.conf.d/custom.conf
pulse.rules = [

    {

        # skype does not want to use devices that don't have an S16 sample format.

        matches = [

             { application.process.binary = "teams" }

             { application.process.binary = "teams-insiders" }

             { application.process.binary = "skypeforlinux" }

        ]

        actions = { quirks = [ force-s16-info ] }

    }

    {

        # speech dispatcher asks for too small latency and then underruns.

        matches = [ { application.name = "~speech-dispatcher*" } ]

        actions = {

            update-props = {

                pulse.min.req          = 1024/48000     # 21ms

                pulse.min.quantum      = 1024/48000     # 21ms

                pulse.idle.timeout     = 5              # pause after 5 seconds of underrun

            }

        }

    }
]
```

### Quirks
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.

- block-record-stream blocks the client from creating any record stream.

- block-playback-stream blocks the client from creating any playback stream.

### update-props
Takes an object with the properties to update on the client. Common actions are to tweak the quantum values. You can use the stream specific keys in pulse.properties.

### startup notification
A newline will be written into the notification file descriptor when the server has started if the following environment variable is set:

•

PIPEWIRE_PULSE_NOTIFICATION_FD

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire-pulse.conf.d/custom.conf
context.modules = [
{   name = libpipewire-module-protocol-pulse

    args = { }
}
]
pulse.properties = {

    server.address = [ "unix:native" ]
}
pulse.rules = [

    {

       # skype does not want to use devices that don't have an S16 sample format.

       matches = [

            { application.process.binary = "teams" }

            { application.process.binary = "teams-insiders" }

            { application.process.binary = "skypeforlinux" }

       ]

       actions = { quirks = [ force-s16-info ] }

   }

   {

       # speech dispatcher asks for too small latency and then underruns.

       matches = [ { application.name = "~speech-dispatcher*" } ]

       actions = {

           update-props = {

               pulse.min.req          = 1024/48000     # 21ms

               pulse.min.quantum      = 1024/48000     # 21ms

               pulse.idle.timeout     = 5              # pause after 5 seconds of underrun

           }

       }

   }
]
```


libpipewire-module-protocol-simple

title: libpipewire-module-protocol-simple(7)

summary: Protocol Simple

text:
# libpipewire-module-protocol-simple(7)

## NAME
libpipewire-module-protocol-simple - Protocol Simple

## DESCRIPTION
The simple protocol provides a bidirectional audio stream on a network socket.

It is meant to be used with the simple protocol player app, available on Android to play and record a stream.

Each client that connects will create a capture and/or playback stream, depending on the configuration options.

You can also use it to feed audio data to other clients such as the snapcast server.

## MODULE NAME
libpipewire-module-protocol-simple

## MODULE OPTIONS

- capture: boolean if capture is enabled. This will create a capture stream or sink for each connected client.

- playback: boolean if playback is enabled. This will create a playback or source stream for each connected client.

- local.ifname = <str>: interface name to use

- local.ifaddress = <str>: interface address to use

- server.address = []: an array of server addresses to listen on as tcp:(<ip>:)<port>.

- capture.props: optional properties for the capture stream

- playback.props: optional properties for the playback stream

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.rate

- audio.format

- audio.channels

- audio.position

- node.latency

- node.rate

- stream.capture.sink

- node.name

- target.object

By default the server will work with stereo 16 bits samples at 44.1KHz.

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-protocol-simple.conf
context.modules = [
{   name = libpipewire-module-protocol-simple

    args = {

        # Provide capture stream, clients can capture data from PipeWire

        capture = true

        #

        # Provide playback stream, client can send data to PipeWire for playback

        playback = true

        #

        #audio.rate = 44100

        #audio.format = S16

        #audio.channels = 2

        #audio.position = [ FL FR ]

        #

        # The addresses this server listens on for new

        # client connections

        server.address = [

            "tcp:4711"

        ]

        capture.props = {

            # The node name or id to use for capture.

            #target.object = null

            #

            # To make the capture stream capture the monitor ports

            #stream.capture.sink = false

            #

            # Make this a sink instead of a capture stream

            #media.class = Audio/Sink

        }

        playback.props = {

            # The node name or id to use for playback.

            #target.object = null

            #

            # Make this a source instead of a playback stream

            #media.class = Audio/Source

        }

    }
}
]
```

## EXAMPLE CONFIGURATION FOR A SNAPCAST SERVER

```
 context.modules = [

 {   name = libpipewire-module-protocol-simple

     args = {

         # Provide sink

         capture = true

         audio.rate = 48000

         audio.format = S16

         audio.channels = 2

         audio.position = [ FL FR ]

         # The addresses this server listens on for new

         # client connections

         server.address = [

             "tcp:4711"

         ]

         capture.props = {

             # Make this a sink instead of a capture stream

             media.class = Audio/Sink

         }

     }

 }

 ]

 On the snapcast server, add the following to the `snapserver.conf` file:
\code{.unparsed}

 [stream]

 sampleformat =  48000:16:2

 source = tcp://127.0.0.1:4711?name=PipeWireSnapcast&mode=client
```

Snapcast will try to connect to the protocol-simple server and fetch the samples from it. Snapcast tries to reconnect when the connection is somehow broken.


libpipewire-module-pulse-tunnel

title: libpipewire-module-pulse-tunnel(7)

summary: Pulse Tunnel

text:
# libpipewire-module-pulse-tunnel(7)

## NAME
libpipewire-module-pulse-tunnel - Pulse Tunnel

## DESCRIPTION
The pulse-tunnel module provides a source or sink that tunnels all audio to a remote PulseAudio connection.

It is usually used with the PulseAudio or module-protocol-pulse on the remote end to accept the connection.

This module is usually used together with module-zeroconf-discover that will automatically load the tunnel with the right parameters based on zeroconf information.

## MODULE NAME
libpipewire-module-pulse-tunnel

## MODULE OPTIONS

- tunnel.mode: the desired tunnel to create, must be source or sink. (Default sink)

- pulse.server.address: the address of the PulseAudio server to tunnel to.

- pulse.latency: the latency to end-to-end latency in milliseconds to maintain (Default 200).

- reconnect.interval.ms: when the remote connection is broken, retry to connect with this interval in millisconds. A value of 0 disables recovery and will result in a module unload. (Default 0) (Since 1.1.0)

- stream.props: Extra properties for the local stream.

## GENERAL OPTIONS
Options with well-known behavior.

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- node.latency

- node.name

- node.description

- node.group

- node.virtual

- media.class

- target.object to specify the remote node.name or serial.id to link to

## EXAMPLE CONFIGURATION OF A VIRTUAL SINK

```
# ~/.config/pipewire/pipewire.conf.d/my-pulse-tunnel.conf
context.modules = [
{   name = libpipewire-module-pulse-tunnel

    args = {

        tunnel.mode = sink

        # Set the remote address to tunnel to

        pulse.server.address = "tcp:192.168.1.126"

        #pulse.latency = 200

        #reconnect.interval.ms = 0

        #audio.rate=<sample rate>

        #audio.channels=<number of channels>

        #audio.position=<channel map>

        #target.object=<remote target name>

        stream.props = {

            # extra sink properties

        }

    }
}
]
```


libpipewire-module-raop-discover

title: libpipewire-module-raop-discover(7)

summary: RAOP Discover

text:
# libpipewire-module-raop-discover(7)

## NAME
libpipewire-module-raop-discover - RAOP Discover

## DESCRIPTION
Automatically creates RAOP (Airplay) sink devices based on zeroconf information.

This module will load module-raop-sink for each announced stream that matches the rule with the create-stream action.

If no stream.rules are given, it will create a sink for all announced streams.

## MODULE NAME
libpipewire-module-raop-discover

## MODULE OPTIONS
Options specific to the behavior of this module

- roap.discover-local = allow discovery of local services as well. false by default.

- raop.latency.ms = latency for all streams in microseconds. This can be overwritten in the stream rules.

- stream.rules = <rules>: match rules, use create-stream actions. See AirPlay Sink for module properties.

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-raop-discover.conf
context.modules = [
{   name = libpipewire-module-raop-discover

    args = {

        #roap.discover-local = false;

        #raop.latency.ms = 1000

        stream.rules = [

            {   matches = [

                    {    raop.ip = "~.*"

                         #raop.port = 1000

                         #raop.name = ""

                         #raop.hostname = ""

                         #raop.domain = ""

                         #raop.device = ""

                         #raop.transport = "udp" | "tcp"

                         #raop.encryption.type = "RSA" | "auth_setup" | "none"

                         #raop.audio.codec = "PCM" | "ALAC" | "AAC" | "AAC-ELD"

                         #audio.channels = 2

                         #audio.format = "S16" | "S24" | "S32"

                         #audio.rate = 44100

                         #device.model = ""

                    }

                ]

                actions = {

                    create-stream = {

                        #raop.password = ""

                        stream.props = {

                            #target.object = ""

                            #media.class = "Audio/Sink"

                        }

                    }

                }

            }

        ]

    }
}
]
```

## SEE ALSO
AirPlay Sink


libpipewire-module-raop-sink

title: libpipewire-module-raop-sink(7)

summary: AirPlay Sink

text:
# libpipewire-module-raop-sink(7)

## NAME
libpipewire-module-raop-sink - AirPlay Sink

## DESCRIPTION
Creates a new Sink to stream to an Airplay device.

Normally this sink is automatically created with RAOP Discover with the right parameters but it is possible to manually create a RAOP sink as well.

## MODULE NAME
libpipewire-module-raop-sink

## MODULE OPTIONS
Options specific to the behavior of this module

- raop.ip: The ip address of the remote end.

- raop.port: The port of the remote end.

- raop.name: The name of the remote end.

- raop.hostname: The hostname of the remote end.

- raop.transport: The data transport to use, one of 'udp' or 'tcp'. Defaults to 'udp'.

- raop.encryption.type: The encryption type to use. One of 'none', 'RSA' or 'auth_setup'. Default is 'none'.

- raop.audio.codec: The audio codec to use. Needs to be 'PCM'. Defaults to 'PCM'.

- raop.password: The password to use.

- stream.props = {}: properties to be passed to the sink stream

Options with well-known behavior.

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- node.name

- node.description

- node.group

- node.latency

- node.virtual

- media.class

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-raop-sink.conf
context.modules = [
{   name = libpipewire-module-raop-sink

    args = {

        # Set the remote address to tunnel to

        raop.ip = "127.0.0.1"

        raop.port = 8190

        raop.name = "my-raop-device"

        raop.hostname = "My Service"

        #raop.transport = "udp"

        raop.encryption.type = "RSA"

        #raop.audio.codec = "PCM"

        #raop.password = "****"

        #audio.format = "S16"

        #audio.rate = 44100

        #audio.channels = 2

        #audio.position = [ FL FR ]

        stream.props = {

            # extra sink properties

        }

    }
}
]
```

## SEE ALSO
RAOP Discover


libpipewire-module-roc-sink

title: libpipewire-module-roc-sink(7)

summary: ROC sink

text:
# libpipewire-module-roc-sink(7)

## NAME
libpipewire-module-roc-sink - ROC sink

## DESCRIPTION
The roc-sink module creates a PipeWire sink that sends samples to a preconfigured receiver address. One can then connect an audio stream of any running application to that sink or make it the default sink.

## MODULE NAME
libpipewire-module-roc-sink

## MODULE OPTIONS
Options specific to the behavior of this module

- sink.props = {}: properties to be passed to the sink stream

- sink.name = <str>: node.name of the sink

- remote.ip = <str>: remote receiver ip

- remote.source.port = <str>: remote receiver TCP/UDP port for source packets

- remote.repair.port = <str>: remote receiver TCP/UDP port for receiver packets

- remote.control.port = <str>: remote receiver TCP/UDP port for control packets

- fec.code = <str>: Possible values: disable, rs8m, ldpc

## GENERAL OPTIONS
Options with well-known behavior:

- node.name

- node.description

- media.name

## EXAMPLE CONFIGURATION

```
 # ~/.config/pipewire/pipewire.conf.d/my-roc-sink.conf

 context.modules = [

  {   name = libpipewire-module-roc-sink

      args = {

          fec.code = disable

          remote.ip = 192.168.0.244

          remote.source.port = 10001

          remote.repair.port = 10002

          remote.control.port = 10003

          sink.name = "ROC Sink"

          sink.props = {

             node.name = "roc-sink"

          }

      }

  }
]
```


libpipewire-module-roc-source

title: libpipewire-module-roc-source(7)

summary: ROC source

text:
# libpipewire-module-roc-source(7)

## NAME
libpipewire-module-roc-source - ROC source

## DESCRIPTION
The roc-source module creates a PipeWire source that receives samples from ROC sender and passes them to the sink it is connected to. One can then connect it to any audio device.

## MODULE NAME
libpipewire-module-roc-source

## MODULE OPTIONS
Options specific to the behavior of this module

- source.props = {}: properties to be passed to the source stream

- source.name = <str>: node.name of the source

- local.ip = <str>: local sender ip

- local.source.port = <str>: local receiver TCP/UDP port for source packets

- local.repair.port = <str>: local receiver TCP/UDP port for receiver packets

- local.control.port = <str>: local receiver TCP/UDP port for control packets

- sess.latency.msec = <str>: target network latency in milliseconds

- roc.resampler.backend = <str>: Possible values: default, builtin, speex, speexdec.

- roc.resampler.profile = <str>: Possible values: default, high, medium, low.

- roc.latency-tuner.backend = <str>: Possible values: default, niq

- roc.latency-tuner.profile = <str>: Possible values: default, intact, responsive, gradual

- fec.code = <str>: Possible values: default, disable, rs8m, ldpc

- resampler.profile = <str>: Deprecated, use roc.resampler.profile

## GENERAL OPTIONS
Options with well-known behavior:

- node.name

- node.description

- media.name

## EXAMPLE CONFIGURATION

```
 # ~/.config/pipewire/pipewire.conf.d/my-roc-source.conf

 context.modules = [

  {   name = libpipewire-module-roc-source

      args = {

          local.ip = 0.0.0.0

          #roc.resampler.backend = default

          roc.resampler.profile = medium

          #roc.latency-tuner.backend = default

          #roc.latency-tuner.profile = default

          fec.code = disable

          sess.latency.msec = 5000

          local.source.port = 10001

          local.repair.port = 10002

          local.control.port = 10003

          source.name = "ROC Source"

          source.props = {

             node.name = "roc-source"

          }

      }

  }
]
```


libpipewire-module-rt

title: libpipewire-module-rt(7)

summary: RT

text:
# libpipewire-module-rt(7)

## NAME
libpipewire-module-rt - RT

## DESCRIPTION
The rt modules can give real-time priorities to processing threads.

It uses the operating system's scheduler to enable realtime scheduling for certain threads to assist with low latency audio processing. This requires RLIMIT_RTPRIO to be set to a value that's equal to this module's rt.prio parameter or higher. Most distros will come with some package that configures this for certain groups or users. If this is not set up and DBus is available, then this module will fall back to using the Portal Realtime DBus API or RTKit.

## MODULE NAME
libpipewire-module-rt

## MODULE OPTIONS

- nice.level: The nice value set for the application thread. It improves performance of the communication with the pipewire daemon.

- rt.prio: The realtime priority of the data thread. Higher values are higher priority.

- rt.time.soft, rt.time.hard: The amount of CPU time an RT thread can consume without doing any blocking calls before the kernel kills the thread. This is a safety measure to avoid lockups of the complete system when some thread consumes 100%.

- rlimits.enabled: enable the use of rtlimits, default true.

- rtportal.enabled: enable the use of realtime portal, default true

- rtkit.enabled: enable the use of rtkit, default true

- uclamp.min: the minimum utilisation value the scheduler should consider

- uclamp.max: the maximum utilisation value the scheduler should consider

The nice level is by default set to an invalid value so that clients don't automatically have the nice level raised.

The PipeWire server processes are explicitly configured with a valid nice level.

## CONFIG OVERRIDE
A module.rt.args config section can be added to override the module arguments.

```
# ~/.config/pipewire/pipewire.conf.d/my-rt-args.conf
module.rt.args = {

    #nice.level = 22
}
```

## EXAMPLE CONFIGURATION

```
context.modules = [
{   name = libpipewire-module-rt

    args = {

        #nice.level   = 20

        #rt.prio      = 88

        #rt.time.soft = -1

        #rt.time.hard = -1

        #rlimits.enabled = true

        #rtportal.enabled = true

        #rtkit.enabled = true

        #uclamp.min = 0

        #uclamp.max = 1024

    }

    flags = [ ifexists nofail ]
}
]
```


libpipewire-module-rtp-sap

title: libpipewire-module-rtp-sap(7)

summary: SAP Announce and create RTP streams

text:
# libpipewire-module-rtp-sap(7)

## NAME
libpipewire-module-rtp-sap - SAP Announce and create RTP streams

## DESCRIPTION
The rtp-sap module announces RTP streams that match the rules with the announce-stream action.

It will create source RTP streams that are announced with SAP when they match the rule with the create-stream action.

If no stream.rules are given, it will announce all streams with sess.sap.announce = true and it will create a receiver for all announced streams.

## MODULE NAME
libpipewire-module-rtp-sap

## MODULE OPTIONS
Options specific to the behavior of this module

- local.ifname = <str>: interface name to use

- sap.ip = <str>: IP address of the SAP messages, default '224.0.0.56'

- sap.port = <int>: port of the SAP messages, default 9875

- sap.cleanup.sec = <int>: cleanup interval in seconds, default 90 seconds

- source.ip =<str>: source IP address, default '0.0.0.0'

- net.ttl = <int>: TTL to use, default 1

- net.loop = <bool>: loopback multicast, default false

- stream.rules = <rules>: match rules, use create-stream and announce-stream actions

- sap.max-sessions = <int>: maximum number of concurrent send/receive sessions to track

- sap.preamble-extra = [strings]: extra attributes to add to the atomic SDP preamble

- sap.end-extra = [strings]: extra attributes to add to the end of the SDP message

## GENERAL OPTIONS
Options with well-known behavior:

•

remote.name

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-rtp-sap.conf
context.modules = [
{   name = libpipewire-module-rtp-sap

    args = {

        #local.ifname = "eth0"

        #sap.ip = "224.0.0.56"

        #sap.port = 9875

        #sap.cleanup.sec = 5

        #source.ip = "0.0.0.0"

        #net.ttl = 1

        #net.loop = false

        stream.rules = [

            {   matches = [

                    # any of the items in matches needs to match, if one does,

                    # actions are emitted.

                    {   # all keys must match the value. ! negates. ~ starts regex.

                        #rtp.origin = "wim 3883629975 0 IN IP4 0.0.0.0"

                        #rtp.payload = "127"

                        #rtp.fmt = "L16/48000/2"

                        #rtp.session = "PipeWire RTP Stream on fedora"

                        #rtp.ts-offset = 0

                        #rtp.ts-refclk = "private"

                        sess.sap.announce = true

                    }

                ]

                actions = {

                    announce-stream = {

                    }

                }

            }

            {   matches = [

                    {   # all keys must match the value. ! negates. ~ starts regex.

                        #rtp.origin = "wim 3883629975 0 IN IP4 0.0.0.0"

                        #rtp.payload = "127"

                        #rtp.fmt = "L16/48000/2"

                        #rtp.session = "PipeWire RTP Stream on fedora"

                        #rtp.ts-offset = 0

                        #rtp.ts-refclk = "private"

                        rtp.session = "~.*"

                    }

                ]

                actions = {

                    create-stream = {

                        #sess.latency.msec = 100

                        #sess.ts-direct = false

                        #target.object = ""

                    }

                }

            }

        ]

    }
}
]
```

Since

0.3.67


libpipewire-module-rtp-session

title: libpipewire-module-rtp-session(7)

summary: RTP session

text:
# libpipewire-module-rtp-session(7)

## NAME
libpipewire-module-rtp-session - RTP session

## DESCRIPTION
The rtp-session module creates a media session that is announced with avahi/mDNS/Bonjour.

Other machines on the network that run a compatible session will see each other and will be able to send audio/midi between each other.

The session setup is based on apple-midi and is compatible with apple-midi when the session is using midi.

## MODULE NAME
libpipewire-module-rtp-session

## MODULE OPTIONS
Options specific to the behavior of this module

- local.ifname = <str>: interface name to use

- control.ip =<str>: control IP address, default '0.0.0.0'

- control.port =<int>: control port, default '0'

- net.mtu = <int>: MTU to use, default 1280

- net.ttl = <int>: TTL to use, default 1

- net.loop = <bool>: loopback multicast, default false sess.discover-local: discover local services as well, default false

- sess.min-ptime = <int>: minimum packet time in milliseconds, default 2

- sess.max-ptime = <int>: maximum packet time in milliseconds, default 20

- sess.latency.msec = <int>: receiver latency in milliseconds, default 100

- sess.name = <str>: a session name

- sess.ts-offset = <int>: an offset to apply to the timestamp, default -1 = random offset

- sess.ts-refclk = <string>: the name of a reference clock

- sess.media = <string>: the media type audio|midi|opus, default midi

- stream.props = {}: properties to be passed to the stream

## GENERAL OPTIONS
Options with well-known behavior:

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- node.name

- node.description

- media.name

- node.group

- node.latency

- node.virtual

- media.class

## EXAMPLE CONFIGURATION

```
 # ~/.config/pipewire/pipewire.conf.d/my-rtp-session.conf

 context.modules = [

 {   name = libpipewire-module-rtp-session

     args = {

         #local.ifname = "eth0"

         #control.ip = "0.0.0.0"

         #control.port = 0

         #net.mtu = 1280

         #net.ttl = 1

         #net.loop = false

         #sess.discover-local = false

         #sess.min-ptime = 2

         #sess.max-ptime = 20

         #sess.name = "PipeWire RTP stream"

         #sess.media = "audio"

         stream.props = {

             node.name = "rtp-sink"

             #audio.format = "S16BE"

             #audio.rate = 48000

             #audio.channels = 2

             #audio.position = [ FL FR ]

         }

     }
}
]
```

Since

0.3.60


libpipewire-module-rtp-sink

title: libpipewire-module-rtp-sink(7)

summary: RTP sink

text:
# libpipewire-module-rtp-sink(7)

## NAME
libpipewire-module-rtp-sink - RTP sink

## DESCRIPTION
The rtp-sink module creates a PipeWire sink that sends audio RTP packets.

## MODULE NAME
libpipewire-module-rtp-sink

## MODULE OPTIONS
Options specific to the behavior of this module

- source.ip =<str>: source IP address, default '0.0.0.0'

- destination.ip =<str>: destination IP address, default '224.0.0.56'

- destination.port =<int>: destination port, default random between 46000 and 47024

- local.ifname = <str>: interface name to use

- net.mtu = <int>: MTU to use, default 1280

- net.ttl = <int>: TTL to use, default 1

- net.loop = <bool>: loopback multicast, default false

- sess.min-ptime = <float>: minimum packet time in milliseconds, default 2

- sess.max-ptime = <float>: maximum packet time in milliseconds, default 20

- sess.name = <str>: a session name

- rtp.ptime = <float>: size of the packets in milliseconds, default up to MTU but between sess.min-ptime and sess.max-ptime

- rtp.framecount = <int>: number of samples per packet, default up to MTU but between sess.min-ptime and sess.max-ptime

- sess.latency.msec = <float>: target node latency in milliseconds, default as rtp.ptime

- sess.ts-offset = <int>: an offset to apply to the timestamp, default -1 = random offset

- sess.ts-refclk = <string>: the name of a reference clock

- sess.media = <string>: the media type audio|midi|opus, default audio

- stream.props = {}: properties to be passed to the stream

- aes67.driver-group = <string>: for AES67 streams, can be specified in order to allow the sink to be driven by a different node than the PTP driver.

## GENERAL OPTIONS
Options with well-known behavior:

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- node.name

- node.description

- media.name

- node.group

- node.latency

- node.virtual

- media.class

## EXAMPLE CONFIGURATION

```
 # ~/.config/pipewire/pipewire.conf.d/my-rtp-sink.conf

 context.modules = [

 {   name = libpipewire-module-rtp-sink

     args = {

         #local.ifname = "eth0"

         #source.ip = "0.0.0.0"

         #destination.ip = "224.0.0.56"

         #destination.port = 46000

         #net.mtu = 1280

         #net.ttl = 1

         #net.loop = false

         #sess.min-ptime = 2

         #sess.max-ptime = 20

         #sess.name = "PipeWire RTP stream"

         #sess.media = "audio"

         #audio.format = "S16BE"

         #audio.rate = 48000

         #audio.channels = 2

         #audio.position = [ FL FR ]

         stream.props = {

             node.name = "rtp-sink"

         }

     }
}
]
```

Since

0.3.60


libpipewire-module-rtp-source

title: libpipewire-module-rtp-source(7)

summary: RTP source

text:
# libpipewire-module-rtp-source(7)

## NAME
libpipewire-module-rtp-source - RTP source

## DESCRIPTION
The rtp-source module creates a PipeWire source that receives audio and midi RTP packets.

This module is usually loaded from the SAP Announce and create RTP streams so that the source.ip and source.port and format parameters matches that of the sender.

## MODULE NAME
libpipewire-module-rtp-source

## MODULE OPTIONS
Options specific to the behavior of this module

- local.ifname = <str>: interface name to use

- source.ip = <str>: the source ip address, default 224.0.0.56. Set this to the IP address you want to receive packets from or 0.0.0.0 to receive from any source address.

- source.port = <int>: the source port

- node.always-process = <bool>: true to receive even when not running

- sess.latency.msec = <float>: target network latency in milliseconds, default 100

- sess.ignore-ssrc = <bool>: ignore SSRC, default false

- sess.media = <string>: the media type audio|midi|opus, default audio

- stream.may-pause = <bool>: pause the stream when no data is reveived, default false

- stream.props = {}: properties to be passed to the stream

## GENERAL OPTIONS
Options with well-known behavior:

- remote.name

- audio.format

- audio.rate

- audio.channels

- audio.position

- media.name

- media.class

- node.name

- node.description

- node.group

- node.latency

- node.virtual

## EXAMPLE CONFIGURATION

```
# ~/.config/pipewire/pipewire.conf.d/my-rtp-source.conf
context.modules = [
{   name = libpipewire-module-rtp-source

    args = {

        #local.ifname = eth0

        #source.ip = 224.0.0.56

        #source.port = 0

        sess.latency.msec = 100

        #sess.ignore-ssrc = false

        #node.always-process = false

        #sess.media = "audio"

        #audio.format = "S16BE"

        #audio.rate = 48000

        #audio.channels = 2

        #audio.position = [ FL FR ]

        stream.props = {

           #media.class = "Audio/Source"

           node.name = "rtp-source"

        }

    }
}
]
```

Since

0.3.60


libpipewire-module-session-manager

title: libpipewire-module-session-manager(7)

summary: Session Manager

text:
# libpipewire-module-session-manager(7)

## NAME
libpipewire-module-session-manager - Session Manager

## DESCRIPTION
This module implements some useful objects for implementing a session manager. It is not yet actively used.

## MODULE NAME
libpipewire-module-session-manager