This adds a GStreamer-based RTP implementation to replace our own. The
original implementation is retained for cases where it is not possible
to include GStreamer as a dependency.
The idea with this is to be able to start supporting more advanced RTP
features such as RTCP, non-PCM audio, and potentially synchronised
playback.
Signed-off-by: Arun Raghavan <arun@arunraghavan.net>
Subdirectories add to the top-level cdata (specifically, the SIMD
detection happens in the pulsecore meson.build), so we were missing
HAVE_MMX/SSE2/NEON defines without this fix.
pulseaudio does not link against libbluetooth, as it's only talking to the
bluez daemon over dbus. So the build dependency on libbluetooth is overly
restrictive, as some embedded systems choose to ship without libbluetooth
but still have bluez daemon support.
This syncs the meson to the autotools configuration behavior by changing
the bluez option to a default on boolean.
For ease of maintaining both build systems, use the same version info
sequences as configure.ac. This should be simplified after Autotools has
been dropped.
- Rename "pulsedspdir" to the same "padsplibdir" that Autotools uses.
- Add a new option "pulsedsp-location" that is only used for padsp.in,
just like Autotools' --with-pulsedsp-location.
- Use 'set' instead of 'set_quoted' to avoid PULSEDSP_LOCATION getting
quoted twice.
Without this, meson on Solaris exits with:
src/daemon/meson.build:138:15: ERROR: Unknown variable "systemd_dep".
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The original atomic implementation in pulseaudio based on
libatomic stated that the intent was to use full memory barriers.
According to [1], the load and store implementation based on
gcc builtins matches sequential consistent (i.e. full memory barrier)
load and store ordering only for x86.
I observed random crashes in client applications using memfd srbchannel
transport on an armv8-aarch64 platform (cortex-a57).
In all those crashes the first read on the pstream descriptor
(the size field) was wrong and looked like it contained old data.
I boiled the relevant parts of the srbchannel implementation down to
a simple test case and could observe random test failures.
So I figured that the atomic implementation was broken for armv8
with respect to cross-cpu memory access ordering consistency.
In order to come up with a minimal fix, I used the newer
__atomic_load_n/__atomic_store_n builtins from gcc.
With
aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425
they compile to
ldar and stlxr on arm64, which is correct according to [1] and [2].
The other atomic operations based on __sync builtins don't need
to be touched since they already are of the full memory barrier
variety.
[1] https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
[2] <https://community.arm.com/developer/ip-products/processors
/b/processors-ip-blog/posts/armv8-a-architecture-2016-additions>
Brings things in line with the autotools build, and adds ALSA mixer
paths and profile-sets into the meson build system as well.
The module installation path is also now customisable.
