When spa-plugins is enabled, the gio-2.0 global dependency is
overwritten.
When bluez support is enabled, OR when gsettings is enabled, the gio-2.0
dependency is then detected as found. This means that
pipewire-module-protocol-pulse can end up enabling gsettings support
even if it has been forcibly turned off.
Rename the meson variables to ensure they are looked up separately.
Most dependencies use meson "feature" options for optional
functionality. This allows people to disable them, if they don't want
them, through the power of tristate decision-making.
This particular dependency does something a bit more complicated than
can be described by simply passing feature options to the required
kwarg. It:
- tries to look for two different names of the dependency
- selects different version ranges, depending on the dependency name
- has a hole in the middle of the versions
Unfortunately, `required: false` for the first dependency isn't
equivalent to a tristate decision-making process. We have to manually
code the logic ourselves.
The problem is that when we look up the first name, we cannot pass the
feature option in because if the option is force enabled, then the
dependency lookup fails and configuration never tries to find the older
version instead.
But also, we can't just say it *isn't* required, because if the option
is force *disabled* but it is installed on the system, we still find it
and build against it.
One solution would be using meson 0.60's support for multiple dependency
names:
```
dependency('webrtc-audio-processing-1', 'webrtc-audio-processing',
version : ['>= 0.2'],
required: get_option('echo-cancel-webrtc'),
)
```
Unfortunately, this too doesn't work since we could end up detecting 1.1
(the hole in the middle) which is invalid.
Instead, we do a bit of checking for tristate values before deciding to
invoke `dependency()`. This lets us guarantee that disabled dependencies
are well and truly disabled.
Bug: https://bugs.gentoo.org/933218Fixes: #3678
Gstreamer 1.24 added and largely switched to a new, modifier aware
DMABuf API. Unfortunately that breaks the existing DMABuf support in the
PW Gst element.
Add support for the new API.
Make a rtprio-server and rtprio-client option. Leave the server
priority by default to 88 but lower client priority to 83. JACK
does something similar by setting clients to rtprio-server - 5.
Make module-rt use the client priority by default and bump the server
priority explicitly in the config file.
Leave the pulse-server to the default rtprio-client, there is no reason
to lower this any further because it is really just a regular client.
Bump the ffado packetizer thread to rtprio-server + 5 because that is
also what JACK does.
88 is still much higher than the value of 60 that JACK uses in
Fedora but now this is at least configurable.
SNAP containers have two main "audio" security rules:
* audio-playback: the applications inside the container can
send audio samples into a sink
* audio-record: the applications inside the container can
get audio samples from a source
Also, old SNAP containers had the "pulseaudio" rule, which just
exposed the pulseaudio socket directly, without limits. This
is similar to the current Flatpak audio permissions.
In the pulseaudio days, a specific pulseaudio module was used
that checked the permissions given to the application and
allowed or forbade access to the pulseaudio operations.
With the change to pipewire, this functionality must be
implemented in pipewire-pulse to guarantee the sandbox
security.
This patch adds support for sandboxing permissions in the
pulseaudio module, and implements support for the SNAP audio
security model, thus forbiding a SNAP application to record
audio unless it has permissions to do so.
The current code for pipewire-pulseaudio checks the permissions
of the snap and adds three properties to each new client:
* pipewire.snap.id: contains the Snap ID of the client.
* pipewire.snap.audio.playback: its value is 'true' if the client
has permission to play audio, or 'false' if not.
* pipewire.snap.audio.record: its value is 'true' if the client
has permission to record audio, or 'false' if not.
These properties must be processed by wireplumber to add or
remove access permissions to the corresponding nodes. That
code is available in a separate patch: https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/567
Use (fixed-up) Doxygen manpage output for all program & module manpages.
This also allows formatting the manual pages properly in the HTML docs.
The Markdown pages work properly only with Doxygen >= 1.9.7, older
versions put them to wrong place in the HTML docs.
Add (minimal) reference documentation for each pipewire-pulse module.
Add some preprocessing to substitute @pulse_module_options@ in docs from
PW_KEY_MODULE_USAGE so the module options don't need to be repeated.
Produce Doxygen docs + generate manpages pipewire-pulse-modules.7,
pipewire-pulse-module-*.7
Use pandoc + some processing to convert Doxygen html output to man
pages.
Requires pandoc & python for building.
Generates manpages: libpipewire-modules.7, libpipewire-module-*.7
Backport from Pulseaudio. Reimplement get_data_path. We'll look for the
override files similarly as we do for other config files
(XDG_CONFIG_HOME then /etc then install location), instead of looking at
the Pulseaudio locations ~/.local/share/pulseaudio etc.
Upstream commits:
From: SimonP <simonp.git@gmail.com>
alsa-mixer: Respect XDG base directory spec when loading profile sets
Try $XDG_DATA_HOME, then $XDG_DATA_DIRS, and finally fall back to old behaviour.
From: SimonP <simonp.git@gmail.com>
alsa-mixer: Respect XDG base directory spec when loading path configs
Try $XDG_DATA_HOME, then $XDG_DATA_DIRS, and finally fall back to old
behaviour (prefix-defined directory).
core-util: Ignore non-absolute XDG base dirs
These are invalid per the spec.
Version 1 does not seem to be packaged in many distros and so they would
need to revert the patch or disable AEC. Enabling both allows for things
to move forwards gracefully.
dlopen lv2 and sofa plugin modules instead of hardcoding them into the+
filter-chain. This also makes it possible to add more plugin module
types externally.
