When configured, reinitialize the module instead of exiting. This
allows a restart/reconnect, but the module to appear to always be alive
when the user does: "pactl list modules". (The sink will still not
exist until the tcp connection is established.)
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/688>
This replaces the original virtual surround sink with a total
rewrite, aiming to implement any number of hrir use cases,
including asymmetrical impulses as two separate left and right
output files. It uses FFTW3 FFT convolution, using the overlap-
save method, with full rewind support. It operates in steps
equal to the resampled length of the hrir, and overlaps input
blocks in increments equal to the size of the FFT block. If
using paired hrirs, it requires matched sample spec and sample
rates and channel maps. For best results, the input files should
have speaker maps, rather than expecting the sample loader to
auto detect the mapping.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/240>
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.
This was being done automatically by autotools, now we need to manually
specify this for each executable/library with a dependency in a
non-standard directory.
For now esound is not supported with the meson build, although it
wouldn't be that hard to support it.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
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.
I can't promise that the logic is *exactly* the same as the logic
currently in use with the autotools, but it seems correct to me.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
If `x11-xcb` is found, then let's force other X11 dependencies to be
there as well. That makes things a bit easier, and that's also what is
done in the autotools build system.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This is to avoid using the construct 'join_paths(prefix, get_option(...))'
everywhere in the meson files. It's better to settle the paths question
once and for all at the beginning.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Regarding the module:
This is unlike the autotools where liboss-util is built as a library,
here we build everything in the oss module, as apparently there's no
other consumer for liboss-util.
Regarding padsp:
Setting the install mode for padsp requires meson 0.47, so instead we
set padsp.in as executable in the git repository (which is what glib
does for gdbus-codegen btw).
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
Please notice that the bluez5 version seems wrong in the dependency
declaration: `>= 4.x`, while we're talking about version 5.
The ofono part will need to be made optional when we start to work on
the meson_options file.
I follow the current configure.ac to define 'HAVE_BLUEZ', but it looks
like this part would benefit from a bit of rework. Setting HAVE_BLUEZ
when we have dbus+sbc sounds weird, there's probably a better name for
this variable.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
This is unlike the autotools where we check that a header exist, here we
use pkgconfig because upstream ships a pkgconfig. I don't know from
which version though...
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>
