Re: [Bluez PATCH v5 0/4] adapter: Reconnect audio when resuming from suspend

[Luiz Augusto von Dentz <luiz.dentz@gmail.com>]

Hi Abhishek,

On Tue, Sep 15, 2020 at 10:41 AM 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 disconnect callback, mark any devices with the A2DP
>    service uuid for reconnect. The reconnect will not be queued until
>    resume.
>  * In the controller resume callback, queue any policy items that are
>    marked to reconnect on resume for connection with the ResumeDelay
>    value (default = 2s).
>
> A reconnect is queued after the controller resumes and the delay
> between resume and reconnect is configurable via the ResumeDelay key in
> the Policy settings. The 2s 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 = 1s 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 on last resume.
> - Suspend test with wake time between 1s - 4s. Ran with 5 iterations and
>   verified it connected several times in the middle and finally at the
>   end.
>
> I've tested this on a Pixelbook Go (AC-9260 controller) and HP
> Chromebook 14a (RTL8822CE controller) with GID6B headset.
>
> I've also tested this with the Pixel Buds 2. These earbuds actually
> reconnect automatically to the Chromebook (even without this policy
> change) and I verified that the new changes don't break the reconnection
> mechanism.
>
> Thanks
> Abhishek
>
>
> Changes in v5:
> - Remove use of !! in has_kernel_features

It seems I end up merging the old version by mistake, but I fixed this
one change myself and added btd_ prefix to it since that is required
to be exported for plugins that are not built-in.

> Changes in v4:
> - Set reconnect timer in disconnect if resume events aren't supported
> - Only set reconnect timer if adapter matches current notification
> - Refactor changes in src/adapter to its own commit
> - Refactor enabling A2DP_SINK_UUID into its own commit
>
> Changes in v3:
> - Refactored resume notification to use btd_adapter_driver
> - Renamed ReconnectAudioDelay to ResumeDelay and set default to 2
> - Added A2DP_SINK_UUID to default reconnect list
>
> Changes in v2:
> - Refactored to use policy instead of connecting directly in adapter
>
> Abhishek Pandit-Subedi (4):
>   adapter: Refactor kernel feature globals
>   adapter: Handle controller resume and notify drivers
>   policy: Enable reconnect for a2dp-sink in defaults
>   policy: Reconnect audio on controller resume
>
>  plugins/policy.c |  87 +++++++++++++++++++++++++++++++++-------
>  src/adapter.c    | 102 +++++++++++++++++++++++++++++++++--------------
>  src/adapter.h    |  11 +++++
>  src/main.c       |   1 +
>  src/main.conf    |  11 ++++-
>  5 files changed, 168 insertions(+), 44 deletions(-)
>
> --
> 2.28.0.618.gf4bc123cb7-goog
>


-- 
Luiz Augusto von Dentz