| Message ID | 20200915174146.1693687-1-abhishekpandit@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | adapter: Reconnect audio when resuming from suspend | expand |
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 >
Awesome, thanks! On Tue, Sep 15, 2020 at 11:05 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > 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