Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
MacBookPro14,1: BCM4350 hybrid coexistence starves Bluetooth audio on 2.4 GHz Wi-Fi
Reported by Clowdyffs · filed Sep 26, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
MacBookPro14,1 (13-inch, 2017, non-T2), BCM4350 rev 5 Wi-Fi (14e4:43a3, brcmfmac), BCM4350C0 UART Bluetooth. Omarchy 4.0.4, linux-omarchy 7.2.5-3, BlueZ 5.87, PipeWire 1.6.8, WirePlumber 0.5.17. Wi-Fi firmware 7.35.180.133, FWID 01-c45b39d6; AirPods Pro 3, A2DP AAC at 48 kHz.
What's wrong?
Bluetooth audio repeatedly cuts out while connected to 2.4 GHz Wi-Fi. A local test tone reproduces it without network streaming. Turning Wi-Fi off makes the tone steady; turning it back on restores the cutouts. Bluetooth discovery was off throughout.
The firmware reports btc_mode=5 (hybrid). Changing only that setting to 4 (parallel) makes both the tone and actual music steady while Wi-Fi stays connected, including a concurrent download at approximately 0.98 MB/s. Restoring mode 5 brings the cutouts back. Codec and volume were unchanged; the music source remained playing and its PCM contained no silent blocks.
One controlled music comparison:
| Firmware mode | AAC packets/s | Median HCI completion delay | RTP sequence gaps |
|---|---|---|---|
| 5, baseline | 15.9 | 481 ms | Repeated |
| 4, Wi-Fi idle | 47.0 | 32 ms | None |
| 4, Wi-Fi download | 46.9 | 35 ms | None |
| 5, restored | 33.8 | 236 ms | Returned |
Expected cadence is 46.875 packets/s. HCI completion delay measures host ACL submission to controller completion, not end-to-end audio latency. The audible result and transport measurements isolate the coexistence policy; the proprietary firmware's internal defect is not established.
This differs from #7384/#1344, which require Bluetooth discovery, and the broader #1288 report does not establish this hardware/policy trigger. Broadcom's definitions identify modes 4 and 5 as parallel and hybrid.
Validated on this machine and one 2.4 GHz access point. Reboot/resume, other routers, and headset microphone calls remain untested. A narrowly guarded NetworkManager dispatcher can reapply the verified policy without a daemon, driver reset, or firmware replacement.
View raw text
### System details MacBookPro14,1 (13-inch, 2017, non-T2), BCM4350 rev 5 Wi-Fi (`14e4:43a3`, `brcmfmac`), BCM4350C0 UART Bluetooth. Omarchy 4.0.4, linux-omarchy 7.2.5-3, BlueZ 5.87, PipeWire 1.6.8, WirePlumber 0.5.17. Wi-Fi firmware `7.35.180.133`, FWID `01-c45b39d6`; AirPods Pro 3, A2DP AAC at 48 kHz. ### What's wrong? Bluetooth audio repeatedly cuts out while connected to 2.4 GHz Wi-Fi. A local test tone reproduces it without network streaming. Turning Wi-Fi off makes the tone steady; turning it back on restores the cutouts. Bluetooth discovery was off throughout. The firmware reports `btc_mode=5` (hybrid). Changing only that setting to `4` (parallel) makes both the tone and actual music steady while Wi-Fi stays connected, including a concurrent download at approximately 0.98 MB/s. Restoring mode 5 brings the cutouts back. Codec and volume were unchanged; the music source remained playing and its PCM contained no silent blocks. One controlled music comparison: | Firmware mode | AAC packets/s | Median HCI completion delay | RTP sequence gaps | | --- | ---: | ---: | --- | | 5, baseline | 15.9 | 481 ms | Repeated | | 4, Wi-Fi idle | 47.0 | 32 ms | None | | 4, Wi-Fi download | 46.9 | 35 ms | None | | 5, restored | 33.8 | 236 ms | Returned | Expected cadence is 46.875 packets/s. HCI completion delay measures host ACL submission to controller completion, not end-to-end audio latency. The audible result and transport measurements isolate the coexistence policy; the proprietary firmware's internal defect is not established. This differs from #7384/#1344, which require Bluetooth discovery, and the broader #1288 report does not establish this hardware/policy trigger. [Broadcom's definitions](https://android.googlesource.com/kernel/common/+/bcmdhd-3.10/drivers/net/wireless/bcmdhd/include/devctrl_if/wlioctl_defs.h) identify modes 4 and 5 as parallel and hybrid. Validated on this machine and one 2.4 GHz access point. Reboot/resume, other routers, and headset microphone calls remain untested. A narrowly guarded NetworkManager dispatcher can reapply the verified policy without a daemon, driver reset, or firmware replacement.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 18:33 UTC