When running meson test without a preceding ninja build, we end up with
missing libraries. This somehow happened to work until recently but now
it triggers an issue with libspa-dbus.so not being available during the
valgrind test run, causing a test case to fail.
Add a method to enable/disable the denormals flush-to-zero and
denormals-as-zero CPU options.
Add a config option to make it possible to disable this again.
Fixes high CPU usage when dealing with denormals, which can happen
in many DSP functions.
Fixes#1681
Some devices (Bose Mini Soundlink II, Air 1 Plus, ...) don't enable
AVRCP volume control, or fail to enable it before a hardware button is
pressed. However, these devices appear to enable it, if an AVRCP player
is present.
As a workaround, register a dummy AVRCP player for each adapter. It only
displays the current transport acquisition state as playing/stopped, but
just its presence appears to be enough to make devices behave.
Multiple AVRCP players interfere with each other, as BlueZ uses the one
registered earliest as the default player. So add also a config option
for disabling this. (It's not common to have mpris-proxy etc. running,
so defaulting to true should be OK.)
See pipewire#1157
The logt function should fall back when both the logger implementation
version is too low or when the method is not implemented.
We can use the new spa_callback_call return value to efficiently
handle this.
Make spa_callbacks_call return true when the method could be called
succesfully. This means the callbacks version was correct and the
method existed.
This can then be used to implement a fallback.
There's a report that on Intel 8086:2723 + Sony WH-1000XM4, the connect
probe shuts the device down.
So, use an invalid dst address instead, since we don't need the host to
be up.
Fixes: 84bc0490a5
Fixes: 717004334b
The msbc capability connection probe seems to cause problems on Intel
Bluetooth 8087:0a2b (Intel 8265), resulting to subsequent connections
apparently ending up with wrong altsetting.
According to testing, the problem is connecting to self, so connect to
device instead.
Fixes#1671
The Doxygen "Modules" page is not very illuminative, as different parts
of the API are mixed together and not all parts are included.
Try to address this:
Put all parts of the public API to some Doxygen group, usually one group
per header file. Use short, systematic names.
Make these groups sub-groups of a few top-level groups, roughly
corresponding to the different logical parts of the API (core, impl,
stream, filter, spa, utilities).
There is a report (#1342) of a device setting multiple bits for AAC
object type in SetConfiguration, although this appears to be forbidden.
It's not completely clear if this was due to e.g. some BlueZ bug, but it
should be safe to be lax and try to guess what is wanted in such case,
instead of being strict, in case it was due to device bug.
This is a leftover from an earlier version of 0e60e9c063. The
attribute is not supported by clang at this time, so let's remove
the #define until we have a use-case that requires it.
Previously, `log-patterns.c` was included in two other source files
(`journal.c` and `logger.c`). It was also specified in the sources
list for the libspa-support library, which resulted in the unnecessary
independent compilation of the file, generating "defined but not used"
warnings.
Extract the function definitions into `log-patterns.h` and
use that in `journal.c` and `logger.c`, and remove the inclusion
of `log-patterns.c` from both.
Don't use the previously skipped sample to calculate the remaining
amount of samples or else we remove one sample too much in some cases
and cause distortion, mostly when downsampling.
Fixes#1646
Add a struct spa_log_topic that allows for logical grouping of messages.
The new macros spa_log_logt() and spa_log_logtv() take a topic as
argument, the topic's level acts as filter.
A new macro spa_log_topic_init() initializes a topic. By default a topic
inherits its logger's debug level but a logger implementation may set
that topic to a specific fixed log level.
The various spa_log_*() macros transparently wrap new and old
implementations:
- if the implementation is version 0, the new logt() calls drop the
topic and get routed into the old log() calls
- if the implementation is version 1, the old log() calls use a NULL
topic and get routed into the new logt() calls
All spa_log_* macros use the SPA_LOG_DEFAULT_TOPIC topic (NULL), it is
up to the caller to redefine that. Alternatively, use spa_logt_* to pass
an explicit topic.
There is one crucial flaw in this implementation: log topics are
initialized to their target level by the current logger. Where a topic
is initialized but the logger is switched later, the topic is not
automatically re-initialized. Ultimately this shouldn't matter for
real-world use-cases.
