fix: throw out all the defensive sleep logic#736
Conversation
|
I noticed an issue when the bluetooth device was connected initially, and then disconnected during the sleep. When the device is woken up again, it thinks the BLE device is still connected. |
|
|
||
| resetAudio = true; | ||
| SetAudioSink(device); | ||
| sleep(1); // give it a moment to apply before we reset the audio system, otherwise |
There was a problem hiding this comment.
Sentence stopped all of a sudden :D But I think I understand you want to wait for bluealsa readiness.
sleep(1) is a full 1second blocking. Wouldn't it be better to poll GetAudioDeviceName() in a short loop until a non-audiocodec device appears (or a timeout is hit)? That way it's fast on quick connections and still safe on slow ones, without always burning a full second.
There was a problem hiding this comment.
Yeah, this was more of a grasping-at-straws bandaid fix that worked after trying different things. One second is harsh, but it is on a background thread.
|
|
||
| asound_state_dir=/tmp/asound-suspend | ||
|
|
||
| log_wakeup_sources() { |
There was a problem hiding this comment.
This needs to be removed before we merge.
…dsets The XRadio BT controller firmware generates link keys with store_hint=0, meaning BlueZ never persists the key to disk. This caused two symptoms: 1. Earbuds disconnect ~2s after pairing: after the BR/EDR bond completes, nothing initiates the A2DP audio profile connection. The earbuds time out waiting for the host to open the audio channel and disconnect (reason 2 = remote terminated). Fixed by calling `bluetoothctl connect` immediately after `bluetoothctl pair` in PLAT_bluetoothPair(). 2. No sound after sleep/wake (fixes #467): bt_init.sh stop/start clears the controller's volatile key memory. On wake, earbuds try to reconnect but BlueZ rejects them (no stored key, JustWorksRepairing=never default). Fixed by patching main.conf to set JustWorksRepairing=always before bluetoothd starts, allowing earbuds to re-initiate the bond from their side without user interaction. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tg5050 (TrimUI Smart Pro S) uses an AIC8800 BT chip, not XRadio. Remove the chip-specific attribution from the comment so it accurately describes the symptom rather than incorrectly referencing XRadio. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…dsets (from #750)
… non-Apple platforms
2 participants
Maybe the BT reconnect fix is removing the hacks you added along the way?