Check if the "TracerPid" field in `/proc/self/status` is non-zero. This does
not need libcap, and does not depend on capabilities, and it also works under
qemu user emulation.
The body code didn't use atomic loads, so it had undefined behavior if
the body was concurrently modified. Use atomic loads to fix this.
Since the memory order is __ATOMIC_RELAXED this has no runtime overhead.
Also add barriers around a strncpy call and cast to volatile before
checking for a NUL terminator, though NUL-terminated strings in shared
memory are unuseable. There are some places where bytewise atomic
memcpy(), which doesn't currently exist, is needed. Instead, try to
fake it by using two barriers around memcpy().
SPA does not respect the C strict aliasing rules at all, so any code
that uses it must be built with -fno-strict-aliasing. Furthermore,
there is code in SPA that compares pointers that point to different
objects, so -fno-strict-overflow is also needed.
One issues is that the `systemd-{system,user}-service` feature options
do not anything without the `systemd` option. This makes it more
complicated to arrive at the desired build configuration since there
are 3^3 = 27 possible ways to set each of them, but if `systemd=disabled`,
then the other two are just ignored.
Secondly, the `systemd` option also influences whether or not libsystemd
will be used or not. This is not strictly necessary, since the "systemd"
and "libsystemd" pkg-config files might be split, and one might wish to
disable any kind of service file generation, but use libsystemd.
Solve the first issues by using the `systemd-{system,user}-service` options
when looking up the "systemd" dependency for generating service files. This
means that the corresponding option is in full control, no secondary options
are necessary. This means that the "systemd" dependency is looked up potentially
twice, but that should not be a significant issue since meson caches dependecy
lookups.
And solve the second issue by renaming the now unused `systemd` option to
`libsystemd` and using it solely to control whether or not libsystemd will
be used.
Furthermore, the default value of `systemd-user-service` is set to "auto" to
prevent the dependency lookup from failing on non-systemd systemd out of
the box. And the journal tests in "test-support" are extended to return "skip"
if `sd_journal_open()` returns `ENOSYS`, which is needed because "elogind"
ships the systemd pkg-config files and headers.
Let's make sure we own the memory in buffers, so that we can be
resilient to the PW link going away. This currently maintains the status
quo of copying data into the pipewirepool for sending to the remote end,
but moves the allocation of buffers so that ownership is maintained by
the sink in all cases.
There are some tricky corners, especially with bufferpool vs. buffers
param negotiation -- bufferpool parameters can be negotiated in
GStreamer before the link even comes up, so we try to adapt the buffers
param to use the negotiated value. For now, that is more brittle than
tying those two aspects together. We can revisit this if we can find a
way to tie pipeline state and link state more closely.
Co-authored-by: Arun Raghavan <arun@asymptotic.io>
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
