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
AUX channels can link to any other channel but when AUX channels are
linked, they must match exactly.
Fixes some issues with split devices with aux channels.
The docs are slightly ambiguous here but it appears a call to
sd_journal_next() is required at least once before the actual data
message.
journalctl positions the cursor with sd_journal_seek_tail() followed by
sd_journal_seek_previous(). The actual enty is then fetched with
sd_journal_next().
Let's do the same here and let's hope this fixes the current race
condition with the test sometimes failing.
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
Debugging is easier if we can explicitly run a single iteration only.
This filter could be a range but for now it's sufficient to be able to
run a single test only.
Take some parts out of the public documentation, add a lot of internal
documentation to make it easier for the next person to figure out how
this works.
The use of static inline prevents doxygen from generating docs, put a
note in to link to the header file directly.
Re-using an id after removing it is a bug in the caller but there are
two cases where we corrupt the free list without warning:
Removing an object twice:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_remove(map, id);
And inserting an element at an index previously removed:
id = pw_map_insert_new(object);
pw_map_remove(map, id);
pw_map_insert_at(map, id, new_object);
The latter is arguably valid code, or at least it'll look like it's
valid code.
For both cases, check if the id to remove/insert at is a free item and
handle that accordingly.
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.
Make Doxygen see also macros defined inside struct declarations,
and to include also opaque structs.
Keep members in the order they are in the .h file, since Doxygen's
case-insensitive sort by name jumbles things.
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 autogenerated graphs are very useful and take up lots of
space being on the top, so disable them.
Also disable references/referenced by relations, which add clutter.
Also hide most macro values.
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).
