Hi, Gentle reminder that this is waiting for feedback. Thanks Abhishek On Tue, Jul 28, 2020 at 6:55 PM Abhishek Pandit-Subedi <abhishekpandit@xxxxxxxxxxxx> 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 >
