have_avx = cc.has_argument(avx_args)
gcc generates an error when AVX is unsupported, whereas clang only
produces a warning.
Thus, using Clang on the RISC-V platform incorrectly enables AVX file
compilation, leading to build failures.
This was added in error (88873e295b) but
we discussed it in !2180 and it turned out CFLAGS="... -fstrict-aliasing"
was set in the environment, overriding the earlier -fno-strict-aliasing
already set in meson.build (which we're keeping here).
That is, when -fno-strict-aliasing is in-effect, there's already no
need for -Wno-error=strict-aliasing (as the warnings aren't emitted), but
if there *is* a need for a -Wno-error=strict-aliasing for a user, it
means they're (likely unintentionally) enabling strict-aliasing and we
certainly want to make them aware of that.
The expression `VBAN_PROTOCOL_SERIAL | vban_BPSList[14]` is assigned
to an 8 bit field of the header, but, `vban_BPSList[14]` being
115200, it does not fit. Instead, its index, 14, should be
placed in the header.
In addition to fixing the issue, add `-Werror=constant-conversion`,
and clang diagnostic that catches such issues.
Fixes: 1a5514e5cf ("module-vban: create streams per stream_name")
Pipewire is designed to be built without strict aliasing enabled (as
evidenced by already hard-coding `-fno-strict-aliasing`). In case people
have strict aliasing warnings enabled by default in their build
environment, explicitly disable errors from those.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
non-systemd systems also have logind, in the form of elogind, which works to
resolve the v4l2 video source race just as well. permit finding elogind, by
using a separate dep object.
To activate:
PIPEWIRE_PROPS='{ video.adapt.converter = video.convert.ffmpeg }' build/src/examples/video-play
This makes it possible to start firefox with mjpg capture and then
video-play and it will decode the mjpeg transparently. Works for other
incompatible video formats as well, as long as they can be mmapped.
Ideally this should use something GPU accelerated and this is what the
vulkan converter will do.
While this is quite fast on x86 (order of a few microseconds), the
computation can take a few milliseconds on ARM (measured at 1.9ms (32000
-> 48000) and 3.3ms (32000 -> 44100) on a Cortex A53).
Let's precompute some common rates so that we can avoid this overhead on
each stream (or any other audioconvert) instantiation. The approach
taken here is to write a little program to create the resampler
instance, and run that on the host at compile-time to generate some
common rate conversions.
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
