Re: [RFC Bluez PATCH 0/3] adapter: Reconnect audio when resuming from suspend

[Abhishek Pandit-Subedi <abhishekpandit@chromium.org>]

Hi,

Gentle reminder that this is waiting for feedback.

Thanks
Abhishek

On Tue, Jul 28, 2020 at 6:55 PM Abhishek Pandit-Subedi
<abhishekpandit@chromium.org> wrote:
>
>
> Hi Luiz and Marcel,
>
> This is a quality of life improvement for the behavior of audio devices
> during system suspend. This depends on a kernel change that emits
> suspend/resume events:
>
> https://patchwork.kernel.org/project/bluetooth/list/?series=325771
>
> Right now, audio devices will be disconnected as part of suspend but
> won't be reconnected when the system resumes without user interaction.
> This is annoying to some users as it causes an interruption to their
> normal work flow.
>
> This change reconnects audio devices that were disconnected for suspend
> using the following logic:
>
>  * In the Device Disconnected management event, if the disconnect reason
>    was 0x5 (Disconnected by Local Host for Suspend) and the device is an
>    audio sink (implements major services Audio + Rendering), then it is
>    queued for reconnect.
>  * When the Controller Resumed management event is seen, we check if
>    an audio device needs to be reconnected. If yes, we queue a delayed
>    callback to do the reconnection. The delay is 5s by default and is
>    meant to allow sufficient time for any Wi-Fi activity that may occur
>    during resume (since Bluetooth connect may adversely affect that).
>
> A reconnect is only attempted once after the controller resumes and the
> delay between resume and reconnect is configurable via the
> ReconnectAudioDelay key in the General settings. The 5s delay was chosen
> arbitrarily and I think anywhere up to 10s is probably ok. A longer
> delay is better to account for spurious wakeups and Wi-Fi reconnection
> time (avoiding any co-ex issues) at the downside of reconnection speed.
>
> Here are the tests I have done with this:
> - Single suspend and verified the headphones reconnect
> - Suspend stress test for 25 iterations and verify both Wi-Fi and
>   Bluetooth audio reconnect on resume. (Ran with wake minimum time of
>   10s)
> - Suspend test with wake time < 5s to verify that BT reconnect isn't
>   attempted. Ran 5 iterations with low wake time and then let it stay
>   awake to confirm reconnect finally completed after 5s+ wake time.
> - Suspend test with wake time between 3s - 6s. Ran with 5 iterations and
>   verified it wasn't connected at the end. A connection attempt was
>   made but not completed due to suspend. A reconnect attempt was not
>   made afterwards, which is by design.
>
>   Luiz@ Marcel@: Does this sound ok (give up after an attempt)?
>
> I've tested this on a Pixelbook Go (AC-9260 controller) and HP
> Chromebook 14a (RTL8822CE controller) with GID6B headset. I'm hoping to
> test this with a few more headsets to make sure this is ok and I'm
> looking for some early feedback.
>
> Thanks
> Abhishek
>
>
>
> Abhishek Pandit-Subedi (3):
>   mgmt: Add controller suspend and resume events
>   monitor: Add btmon support for Suspend and Resume events
>   adapter: Reconnect audio on controller resume
>
>  lib/mgmt.h       | 14 +++++++++
>  monitor/packet.c | 55 ++++++++++++++++++++++++++++++++
>  src/adapter.c    | 82 ++++++++++++++++++++++++++++++++++++++++++++++++
>  src/device.c     | 27 ++++++++++++++++
>  src/device.h     |  2 ++
>  src/main.conf    |  6 ++++
>  6 files changed, 186 insertions(+)
>
> --
> 2.28.0.rc0.142.g3c755180ce-goog
>