#232 Mac: Audio session thrash while Carrier is running breaks Bluetooth audio system-wide on macOS

[Anonymous]

Originally created by: bcvictory

Hi, thanks for building this. It's the only Messenger app I've found that isn't a 200MB Electron wrapper, so I'd rather get this fixed than drop it.

I spent a few hours yesterday chasing what I thought was a broken pair of AirPods, and it turned out to be Carrier. Writing it up in case it's useful.

What happens

While Carrier is running, my AirPods Pro go silent after any gap in playback. Every app is affected, not just Carrier. The playhead keeps moving, the AirPods stay selected as the output device, and there's no sound. The only way to get audio back is switching output to another device and back, and then it dies again on the next pause.

Quitting Carrier fixes it immediately. It comes straight back when I relaunch.

Touch ID on my Magic Keyboard also stopped working while Carrier was open, and started working again the moment I quit. I can't prove that's the same root cause, but the timing lined up exactly.

What's in the logs

Carrier's WKWebView flips its audio session category about once a second, continuously, with no call running and no interaction:

AudioStateChanged: Added audio session app com.apple.WebKit.GPU 20 -> 201 count 1
AudioStateChanged: Added audio session app com.apple.WebKit.GPU 201 -> 20 count 1

That's roughly 60 flips a minute, sustained for hours. Each one triggers a Bluetooth route re-evaluation in audioaccessoryd:

BTAudioRoutingRequest, CID 0xAAEA0001, auSc 201, dAdr <airpods>, flags 0x1 < Hijack >
PredictiveRoute: Evaluating localScore 201 currentRoute Bluetooth delay 2.00s

Counting the flips per minute across the moment I quit Carrier:

19:29   60
19:30   54
19:31   36   (quit here)
        (nothing after)

Confirmed the WebKit process belonged to Carrier:

$ sudo launchctl procinfo 33317 | grep responsible
responsible path = /Applications/Carrier.app/Contents/MacOS/carrier

The audio was still being transmitted the whole time, which is what made this hard to find. A2DP link quality reports showed full payload packets leaving the Mac while I could hear nothing, so the constant route churn seems to stop the headphones settling on the stream rather than the audio never being sent.

Reproduce

1. Connect AirPods or any Bluetooth headphones to a Mac.
2. Launch Carrier and leave it open. No call, no interaction needed.
3. Run /usr/bin/log stream --predicate 'process == "audioaccessoryd"' --style compact | grep 'Added audio session'
4. Play audio in any app, pause for 30 seconds, hit play again.

Environment

• Carrier 1.8.0
• macOS 27.0 (build 26A5406e)
• MacBook Pro, Apple silicon
• AirPods Pro, firmware 9A336b

The ask

Is something in the webview or the Messenger page claiming and releasing an audio session on a timer? My guess is it's tied to keeping call audio ready, but I'm not across Tauri's internals so I could be well off. If the session only got claimed when a call actually starts, I think that would sort it.

Happy to run whatever logging would help and send the output. I've still got the full capture from yesterday if you want it.

[Anonymous]

Originally posted by: kristofferR

Ah, thanks for this report, I'll look more into it!

I've experienced the same issue before, but were sure it was just a Golden Gate bug (am running the betas), so I didnt look into it.

[Anonymous]

Ticket changed by: kristofferR

• status: open --> closed

[Anonymous]

Originally posted by: kristofferR

Thanks again, I've just released 1.9.0 which has a lot of macOS improvements and also a bug fix for this, hopefully it fixes it!

[Anonymous]

Originally posted by: kristofferR

Unfortunately not completely fixed. I'm working on it more in https://github.com/kristofferR/Carrier/issues/234