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.
It seems not uncommon that people have not properly configured ofono
running, which results to loss of HFP/HSP functionality. It's less
surprising if the backend selection is fixed in the configuration file,
and (by default) does not depend on running services.
Add a configuration file option for selecting HFP/HSP backend, and set
the default value to the native backend. Emit warnings if conflicting
backend services are detected to be running.
Also cleanup hfp/hsp backend handling a bit, now that it's mostly
abstracted behind an interface.
It's not really the responsibility of the session manager to load the
bluez5 device quirks, and it's easier for eg. Wireplumber if it doesn't
need to do it.
Move loading bluez-hardware.conf to be the responsibility of the bluez5
spa plugin, similarly as the alsa plugin deals with the ACP database.
Put the configuration to share/spa-0.2/bluez5, mirroring the plugin
directory structure in lib/spa-0.2/bluez5.
In one we can duplicate the spa_asprintf call without real drawbacks.
The second one can be split up without losing details. Note that there
is another one in backend-native.c where splitting it up will make the
code harder to understand. The warning for that one remains.
Change codec factory names to api.codec.bluez5.*, so that they won't
conflict with old config file lib name rules for api.bluez5.*
Specify the fallback library name when loading the codecs, so that it
works without the rules in config files.
Make easier to package A2DP codecs separately, by splitting each to a
separate SPA plugin. Adjust the code to not use a global variable for
the codec list.
The A2DP SPA interface API is in the bluez5 private headers, and not
exposed in installed SPA headers, as it's too close to the
implementation.
If you use multiple BT adapters, it's annoying that PW tries to
autoconnect to the device via all available adapters, and you end up
with multiple connections to the same device (which does not necessarily
work).
Avoid this by autoconnecting with only the first adapter that sees the
device.
We don't currently implement encoding for the duplex channel
for these codecs, so they are not fully functional as A2DP sinks,
and their main use is anyway with headphones.
Also, the number of endpoints in BlueZ appears to be limited, and
appears to be counted across all adapters. Unclear whether this comes
from AVDTP limitation, but currently plugging in a second BT adapter
causes the second media application registration to fail. This change
reduces the number of endpoints enough so that registration succeeds for
two adapters.
There doesn't seem to be a way to control the A2DP duplex microphone
HW volume gain, and devices sometimes have very low mic volumes.
Work around this by boosting the software volume scale by +20 dB. If it
causes clipping, the user can just reduce the volume to bring SW gain
below 1.0.
aptX-LL sink devices may send back mSBC encoded data corresponding to
microphone input. It appears to be enabled when the bidirectional link
is set in the caps, and the device also supports this.
Implement mSBC decoding in the duplex channel.
Tested to be working on Avantree Aria Pro.
For unknown reason the BT socket when working with A2DP "duplex" stream,
sometimes stops waking up poll when data arrives. Regardless, recv() can
read data packets from it.
To work around this, when A2DP source is in duplex mode, instead of
polling on data, we poll on a timer.
Some non-standard A2DP codecs (FastStream/aptX-LL) have "voice duplex
channel" that can be used to provide an A2DP duplex mode.
Add support for duplex channels, accounting for the fact that the two
directions may be encoded with different actual codecs.
This pushes the latency to 256 samples, which still seems to work
Latency of 128 seems to be too small. (NB. the number of input samples
is also the size of packets sent in bytes)
Since pipewire clients usually use powers of two, this may be the
smallest value that makes sense.
Support the low-latency variant of the aptx codec.
The magic mostly seems to be on the device side, since the stream is the
same as standard aptx, but latency is smaller even if stream/packet
sizes are the same.
Sound output latency is noticeably less than with the standard aptx.
Tested on Sennheiser HD 250 / Avantree Aria Pro.
The codec in principle also supports bidirectional duplex streams,
but that is not implemented here.
The codec IDs are user-visible properties.
Some codecs can have multiple endpoints (e.g. different caps struct, or
multiple possible vendor ids), so this detail should not leak to the
user.
Disable flush polling when we don't have data ready to write to the
socket (or socket send failed). This avoids entering into a poll busy
loop, which may result to rtkit killing the process.
Enable SBC-XQ by default, and move it at the end of the codecs list, so
that bluez does not connect to it automatically except when it is the
codec used previously.
When the codec is disabled by quirks, it won't appear in the codecs
list, and so can't be selected by user (and so won't be connected
automatically).
However, since SelectConfiguration does not carry information which
device is in question, we cannot prevent BlueZ connecting to the codec
even if it's disabled for a specific device. If the "impossible" occurs
regardless, we won't reject the connection and the profile will be shown
as the generic "A2DP" one. If the sound is garbled, the user can select
some other profile that works.
