GitLab

Whenever a device disconnects the device is not removed from BlueZ, only
the profiles that had an active connection are disconnected. Since we
were providing this battery level based on AT commands received through
HSP/HFP these services should be responsible for deregistering it again.

Deregister the interface to signal BlueZ (And UPower in return) that the
battery level won't be accurate/updated anymore.

The peer will wait some time and eventually time out the connection if
no reply is sent back. When sending `ERROR` the peer can decide to break
the RFCOMM connection immediately or continue when a command is not
critical.

Devices for Apple's iOS uses a few extra HFP AT commands to
inform the iPhone about the headphone's battery status.
Apple documented the AT commands in the following document:

https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

The patch has been tested with a Bose QC35, which results
in the following communication:

D: [pulseaudio] backend-native.c: RFCOMM << AT+VGS=14
D: [pulseaudio] backend-native.c: RFCOMM >> OK
D: [pulseaudio] backend-native.c: RFCOMM << AT+XAPL=009E-400C-0129,3
D: [pulseaudio] backend-native.c: RFCOMM >> +XAPL=iPhone,2
D: [pulseaudio] backend-native.c: RFCOMM >> OK
D: [pulseaudio] backend-native.c: RFCOMM << AT+XEVENT=Bose SoundLink,158
D: [pulseaudio] backend-native.c: RFCOMM >> OK
D: [pulseaudio] backend-native.c: RFCOMM << AT+IPHONEACCEV=2,1,4,2,0
N: [pulseaudio] backend-native.c: Battery Level: 50%
N: [pulseaudio] backend-native.c: Dock Status: undocked
D: [pulseaudio] backend-native.c: RFCOMM >> OK

[Marijn: Adapt for recent HSP/HFP code changes]
Co-authored-by: Marijn Suijten <marijns95@gmail.com>

A few headsets have issues if HFP HF profile connection is attempted before
HSP HS profile connection is closed. Looks like this could happen because
bluez bluetoothd alows to make simultaneous HSP HS and HFP HF peer connections.

One of affected headsets is WH-1000XM2

Until we find out how to prevent simultaneous HSP HS and HFP HF connections,
when native backend has HFP HF profile enabled (this is the default) do disable
HSP HS completely unless user explicitly request it via discovery modarg.

Do this by adding module-bluetooth-discover arg enable_native_hsp_hs,
default to inverse of enable_native_hfp_hf.

Part-of: <!538>

HFP HF peer can send +BAC= list of codecs in any order and pa only expects "1,2"
Fix this by actually parsing codec list elements while looking for "2" (mSBC)

Part-of: <!537>

to clarify that only mutating proplist calls potentially invalidate results
of earlier get requests, thus addressing the confusion found at [1].

[1]: https://github.com/jnqnfe/pulse-binding-rust/issues/38

Part-of: <!536>

Part-of: <!507>

Add module-bluetooth-discover argument enable_msbc, default is true (enabled)

Part-of: <!507>

Common API for all bluetooth codecs is now pa_bt_codec.
API to negotiate and configure A2DP SEP over Bluez is now pa_a2dp_endpoint_conf.

Part-of: <!507>

Raise initial MTU size to fix frame size when hci can do 60 byte frames.

Part-of: <!507>

Part-of: <!507>

We are supposed to conceal packet loss. This is not trivial but we can at least
produce silence instead of breaking on mSBC decoding error.

Part-of: <!507>

Part-of: <!507>

While codec switching for HFP is not implemented, show current codec via
messaging api.

Part-of: <!507>

Part-of: <!507>

Bluetooth SCO is synchronous stream, make our writes more uniformly paced.
To do this, first separate writing to socket from rendering a frame.

Part-of: <!507>

If input block size is shorter than SBC frame codesize, encoder will return 0.
Log this and skip whole input block.

Part-of: <!507>

This is a workaround for hardware/driver which inserts all-zero packets in what
otherwise looks like a valid mSBC stream.

Part-of: <!507>

For mSBC to work correctly the following must be set correctly
- codec object
- transport write method
- transport setsockopt method

Use helper method to set all three simultaneously.
Static configuration structure may be cleaner solution.

Part-of: <!507>

HFP Audio Connection SCO configuration is negotiated symmetrically in both
directions, and USB HCI SCO packet framing is also symmetric in both directions.
This means that packet size will be the same for reads and writes over HFP SCO
socket.

HFP profile specification states that valid speech data shall exist on the
Synchronous Connection in both directions after the Audio Connection is
established.

This guarantees that an incoming packet will arrive shortly after SCO connection
is established. Use it's size to fix write MTU in case kernel value is wrong.

Discussion here https://lore.kernel.org/patchwork/patch/1303411/

Part-of: <!507>

The HFP protocol supports the ability to negotiate codecs if that is
supported by both AG and HF.  This patch adds advertising of codec
negotiation support and the ability to negotiate a codec change.  The
only currently supported extra codec (as of HF 1.7.1) is mSBC.  mSBC
requires that the transmission be done over an eSCO link with
Transparent Data.  The linux kernel ensures the former, but we have to
manually set the socket to transparent data.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Part-of: <!507>

Adding processing support for the mSBC codec is somewhat problematic,
because, although it is a SBC codec, the a2dp handling can't simply be
reused because the codec is used on an eSCO link with transparent
data, meaning the transmission unit has to be 48 bytes (fragmenting
the codec packets) and reassembly and boundary detection is required
to be done by the implementation.  Therefore we have to implement
separate render and push routines for msbc that do this fragmentation.

Fragmentation is done by emulating circular buffers.  The receive
(push) buffer is easy, since the mSBC packet size is 60, simply have a
buffer of this size in the sbc_info area where the fragments are
reassembled.  Once we have a full 60 bytes, decode and restart from
zero.  The send (render) buffer is more problematic, since the
transmit must be done from contiguous memory.  This means that the
buffer must be the lowest common multiple of the transmission unit and
the packet size.  This value is 240 since 240/48 == 5 and 240/60 == 4.
So the buffer pointers are reset at 240 which is a whole number of
both rendered packets and eSCO transmission units.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Part-of: <!507>

Part-of: <!507>

Part-of: <!507>

Part-of: <!507>

When an application sets a device for a newly created stream, we treat
that as a temporary setting, and don't save it as the preferred device
for future streams. The handling for this was broken, however: if the
stream already had a preferred device saved in the stream-restore
database, that was unset.

This was a regression introduced in
bc0e7283 and
70bbbcdc. These commits tried to detect
in subscribe_callback() when the preferred device is cleared, but as a
side effect the preferred device started to get cleared from the
database also when a stream was created with a device set by the
application.

There's no way for subscribe_callback() to distinguish the different
cases of the preferred device being NULL. This problem is solved by
using the PREFERRED_SINK/SOURCE_CHANGED hooks. The hooks are only called
when the preferred device really changes.

Fixes: #1063
Part-of: <!535>

The hooks are fired when the preferred device changes. This is useful
for module-stream-restore.

I added new set_preferred_sink/source() functions for firing the hooks.
The functions also log the preferred device changes.

There was already pa_sink_input_set_preferred_sink(), but that had a
side effect of moving the stream, so I needed a new function. Since it
can be confusing when the two similarly named functions should be
called, I added a comment for pa_sink_input_set_preferred_sink() that
explains the different situations.

Part-of: <!535>

Bluez prepends newly registered profile to a list of supported profiles,
and new peer profile connections are attempted in reverse order of profile
registration.

Currently native backend would register HFP AG profile before HSP AG profile.
When peer supports both HFP HF and HSP HS profiles, this registration order
causes extra HSP HS connection attempt before native backend would reject it
to make sure peer is reconnected with HFP HF profile.

Reorder HSP AG profile registration before HFP AG to make sure peer supporting
both profiles connects with HFP HF profile first.

Part-of: <!534>

Part-of: <!525>

Part-of: <!525>

Part-of: <!525>

Part-of: <!525>

Use 64bit signed integers and fix double value conversion.

Part-of: <!525>

Setting these callbacks adds the HW_{VOLUME,MUTE}_CTRL flag even when
PulseAudio is solely responsible for performing attenuation whilst only
keeping the peer posted on changes.  For this case the hardware callback
is not registered at all but instead a hook is attached to catch
PA_CORE_HOOK_{SINK,SOURCE}_VOLUME_CHANGED.  Only when the peer performs
attenuation (the peer is in HeadSet/HandsFree role) are the callbacks
used, without touching PA software volume at all.  A future change could
potentially use software volume to compensate for the extremely coarse
16 steps of volume control in HSP and HFP, and to allow volume over
100%.

Part-of: <!519>

Since commit cb91d7a1 the watermark is increased when there is nothing to rewind.
This is also done in the case when there was actually no rewind requested at all,
so the watermark is increased needlessly.
This patch fixes the issue by skipping the rewind if none is requested.

Part-of: <!530>

Part-of: <!359>