Bluetooth initialization lag — root cause and findings

[noisetta]

After investigating the Bluetooth lag issue that several of us have been experiencing, here are some findings:
It looks like the root cause is hardcoded sleep calls in /usr/bin/bt_init totalling 11 seconds of fixed delays:

sleep 5 after brcm_patchram_plus
sleep 1 after hciconfig up
sleep 1 after hciconfig reset
sleep 2 after bt-agent
sleep 1 after bluealsa
sleep 1 after sdptool

Replacing the fixed sleeps with condition-based waits (polling for hci0 in 100ms intervals) and reduced the remaining sleeps to 0.3–0.5s brings down the initialization time from ~11 seconds to ~7 seconds.

The remaining 7 seconds breaks down as:

~4 seconds — Broadcom BCM4343A1 firmware loading via brcm_patchram_plus — this is hardware limited and can't be reduced without modifying the firmware loader itself
~2 seconds — remaining necessary sleeps
~1 second — actual service startup

The optimized bt_init will most likely be included in the next firmware release. The 4 second hardware limit is likely the best we can achieve without deeper work on the Broadcom firmware loading process (@Tartarus6 , any ideas ?).

[Tartarus6]

@noisetta, that's a big improvement

the only thing I can think of to help further is doing things asynchronously. that could help make the lag not really matter that much

if it doesn't already do it async

[noisetta]

Good thinking — I actually dug into this after your reply. Turns out S80_bt_init already launches bt_init with & in the background, so it's been async all along. The player uses /tmp/bt_init_ok as a readiness flag rather than blocking on BT at boot.

So the 7s we're seeing after the optimization is essentially the hardware floor — the Broadcom BCM4343A1 firmware load via brcm_patchram_plus accounts for about 4s of that and there's no getting around it. The other 3s we already recovered by replacing the hardcoded sleeps with condition-based polling.

Unless there's a way to speed up the Broadcom firmware load itself, I think we're at the limit on this one.

[Tartarus6]

cool, good that it's figured out