A2DP profile may disappear if several SetConfiguration events occur too
rapidly. Rate limit these calls when switching codecs.
This resolves failures if e.g. the session manager attempts to set the
profile immediately after the device is created, which previously might
cause a failure.
Higher priority for A2DP over HFP/HSP. Prefer mSBC over CVSD for HFP,
and put A2DP codecs in the order we tell BlueZ to use.
Ensures that picking highest-priority profile gives sensible results
(e.g. does not pick HFP unless input route is required, and prefers A2DP
duplex codecs over HFP).
Make the alignment parameter optional when negotiating buffers.
Default to a 16 bytes alignment and adjust for the max cpu
alignment.
Remove the useless align buffer parameter in plugins, we always
set it to 16 anyway.
First check if the bluez dbus service is active before doing a
GetManagedObjects() call.
Else we might try to activate the bluetooth dbus service, which
should normally only be activated during bootup.
Simplify the key-value pair parsing for AT+IPHONEACCEV commands,
and move the handling of {key,indicator}-value pairs into
dedicated functions. Furthermore, fix a comment.
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
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
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.
Intel 8087:0029 at Firmware revision 0.0 build 191 week 21 2021 on
kernel 5.13.19 produces CVSD data stream that consists of 96-byte data
packets interleaved with 96-byte zero packets.
This seems to not occur on other adapters, which usually produce only
48-byte data packets.
Don't do a blocking probe of native backend presence, because it may
trigger DBus activation for Bluez. If the DBus activation fails, it
ends up blocking until timeout.
ofono/hsphfpd usually don't have DBus activation configured, so they
fail instantly (which is why this problem was not encountered, even
though they do blocking calls on startup in previous pipewire versions
too).
Instead, select the backend once we have Bluez objects listed.
BlueZ 6 is planning to make most of libbluetooth private. In
particular, the direct hci access is planned to be removed. This is
currently used for determining adapter msbc support.
Instead of using libbluetooth API, try to determine msbc support by
a connect() attempt, which the kernel should reject when not supported.
