The Hackintosh era might be nearing its end, but the pursuit of perfection and tinkering never stops.

Here's a well-known issue that has been annoying the community for years:

https://github.com/OpenIntelWireless/IntelBluetoothFirmware/issues/462

For example, my AirPods Pro 2 would connect perfectly fine, but there would be absolutely no sound when playing music or watching videos. Sometimes, disconnecting and reconnecting works, or switching audio outputs with BlackHole 2ch multiple times can temporarily glitch it into working. But 99% of the time, it just fails. It's incredibly frustrating. Oddly enough, other Bluetooth headphones work fine, even knockoff AirPods.

After two days and nights of analysis, and with some assistance from Codex, Claude, and Gemini, I've finally solved it!

I spent some time reverse-engineering bluetoothd and pinpointed the critical conditional jump. I wrote a patch to bypass this check entirely, allowing the audio channel to establish normally. I've tested it on macOS 26.4 Tahoe + Intel AX201 + AirPods Pro 2, and it works flawlessly—sound plays immediately upon connection.

The Root Cause:

When macOS's bluetoothd tries to establish an audio stream, it attempts to read the Bluetooth clock (HCI_Read_Clock). Intel and some other third-party wireless cards either don't support this or respond too slowly. As a result, the system simply kills the A2DP channel. If you check your console, you'll see Failed to read BT clock spamming your logs.

Theoretically, this patch should support all versions from macOS 12 to 26. However, I only have a 26.4 environment on hand. I would really appreciate it if you guys could test it on other macOS versions and drop some feedback.

https://github.com/hexxyan/BlueToolFixup-FixA2DP/

(Please drop a star if this helps you out!)

How to use:

1. Download this specific release and replace your existing BlueToolFixup.kext: https://github.com/hexxyan/BlueToolFixup-FixA2DP/releases/tag/2.7.3
2. Add -btlfxa2dpcheck to your boot-args.
3. Reboot.

Note: If you don't add the boot argument, the patch will remain inactive, so you don't have to worry about it breaking your existing, working setup.

I've already submitted a PR to the upstream BrcmPatchRAM repository here:

https://github.com/acidanthera/BrcmPatchRAM/pull/38

If you are interested in the technical details and my reverse-engineering process, I've documented everything here:

https://github.com/hexxyan/BlueToolFixup-A2DP-Documentation

Let me know if you run into any issues. Any feedback is welcome!