This is important for cross-platform build frameworks such as Yocto
where the build configurations must be deterministic. In this case, if
some other build dependency pulled in SDL2, then the meson.build logic
would suddenly enable extra features that would not have been built
otherwise. By allowing for explicitely enabling/disabling SDL2 and sndfile
depending bits, this problem is fixed.
In particular ACP_PATHS_DIR, ACP_PROFILES_DIR ended up pointing to the
build directory, despite only existing in the source directory.
I also adjusted PIPEWIRE_CONFIG_DIR to be explicit about referencing
the build directory, given that the other environment variables are
doing so.
Fixes: #448
This variable describes whether we have systemd and libsystemd,
not just <systemd/sd-daemon.h>
While at it, sneak in a fix for the warning message:
"systemd should never ever be capitalized".
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
This is necessary on some 32-bit architectures that implement atomic
operations on 64-bit quantities as library calls, including Debian's
armel and mipsel ports.
Signed-off-by: Simon McVittie <smcv@debian.org>
As hsphfpd is a prototype and its API subject to change, this backend is
disable by default.
This skeleton connects to hsphfpd daemon and list the managed devices.
PIPEWIRE_CORE can be used to specify a server name.
PIPEWIRE_REMOTE can be used to specify what server name to
connect to.
Either use the absolute path of the name to create and connect
to a server, or use a relative path. For a relative path, the
server name will be completed by prefixing the following paths
in order:
PIPEWIRE_RUNTIME_DIR environment variable,
XDG_RUNTIME_DIR environment variable,
HOME environment variable,
USERPROFILE environment variable,
home directory as stored in the password database.
Fixes#259
libacp is a port and wrapper around the pulseaudio card profile code.
It uses a set of templates for construct a card profile and mixer port
settings. It also has support for UCM when available for the hardware.
This makes it easier to test PipeWire in its "as-installed" state,
for example in an OS distribution.
The .test metadata files in ${datadir}/installed-tests/${package} are
a convention taken from GNOME's installed-tests initiative, allowing a
generic test-runner like gnome-desktop-testing to discover and run tests
in an automatic way.
The installation path ${libexecdir}/installed-tests/${package} is also
a convention borrowed from GNOME's installed-tests initiative.
In addition to the automated tests, I've installed example executables
in the same place, for manual testing. They could be separated into
a different directory if desired, but they seem like they have more
similarities with the automated tests than differences: both are there
to test that PipeWire works correctly, and neither should be relied on
for production use. Some examples are installed in deeper subdirectories
to avoid name clashes.
Signed-off-by: Simon McVittie <smcv@debian.org>
On GNU/Linux systems, the literal string '${LIB}' in dynamic linker
paths expands to "lib", a biarch libQUAL directory such as "lib64", or
a Debian-style multiarch directory such as "lib/x86_64-linux-gnu".
If we're installing libraries to such a directory, and we have both
word-sizes' compatibility libraries available, then pw-pulse can
use LD_LIBRARY_PATH='/usr/${LIB}/pipewire-0.3/pulse' to make both
i386 and x86_64 programs load the correct version.
Signed-off-by: Simon McVittie <smcv@debian.org>
due to usage of VK_ERROR_OUT_OF_POOL_MEMORY, VK_ERROR_INVALID_EXTERNAL_HANDLE,
VK_API_VERSION_1_1 and VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT
introduced in version 1.1.69
Signed-off-by: Martin Koch <martin.koch@ese.de>
