From: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
To: luiz.dentz@gmail.com, marcel@holtmann.org
Cc: chromeos-bluetooth-upstreaming@chromium.org,
linux-bluetooth@vger.kernel.org,
Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Subject: [RFC Bluez PATCH 0/3] adapter: Reconnect audio when resuming from suspend
Date: Tue, 28 Jul 2020 18:55:37 -0700 [thread overview]
Message-ID: <20200729015540.1848987-1-abhishekpandit@chromium.org> (raw)
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
next reply other threads:[~2020-07-29 1:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-29 1:55 Abhishek Pandit-Subedi [this message]
2020-07-29 1:55 ` [RFC Bluez PATCH 1/3] mgmt: Add controller suspend and resume events Abhishek Pandit-Subedi
2020-07-29 1:55 ` [RFC Bluez PATCH 2/3] monitor: Add btmon support for Suspend and Resume events Abhishek Pandit-Subedi
2020-07-29 1:55 ` [RFC Bluez PATCH 3/3] adapter: Reconnect audio on controller resume Abhishek Pandit-Subedi
2020-08-04 18:54 ` Luiz Augusto von Dentz
2020-08-06 3:48 ` Abhishek Pandit-Subedi
2020-08-06 17:20 ` Luiz Augusto von Dentz
2020-08-04 17:12 ` [RFC Bluez PATCH 0/3] adapter: Reconnect audio when resuming from suspend Abhishek Pandit-Subedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200729015540.1848987-1-abhishekpandit@chromium.org \
--to=abhishekpandit@chromium.org \
--cc=chromeos-bluetooth-upstreaming@chromium.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).