fix(macos): prevent silent AirPods recordings when also playing audio from iPhone

[mattdoran]

When an iPhone is playing through AirPods, macOS can open the AirPods microphone without reporting an error but deliver only zero samples. Handy then produces no transcription or History entry.

On macOS, look for an output device whose reported name exactly matches the selected input device. If one exists, open a silent output stream alongside the microphone stream. This restores microphone samples in the tested AirPods state, while inputs without an exact-name output match are unchanged.

Fixes #1990

Without this change Handy feels unreliable and can lose recordings.

Please confirm you have done the following:

• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

Testing

macOS 26.6.2 (MacBook Pro, Apple M1 Max), AirPods Pro, iPhone on iOS 26.6.

To reproduce without the patch: play audio from an iPhone to AirPods set to switch automatically, then record in Handy. The log ends with sample count: 0 and nothing is saved. With the patch the same recording transcribes normally, and the iPhone's playback stops, the same way it does when you hit record in QuickTime Player or Voice Memos.

Recording from the built-in microphone is unaffected. The keep-alive stream is only opened when an output device exists under the same name as the input, which is not the case for the built-in mic (MacBook Pro Microphone against MacBook Pro Speakers). A USB headset that names its input and output identically would get one, which seems right but I have not tested it.

I also used a small standalone CoreAudio client to confirm the device really was returning all-zero samples at that moment rather than just quiet audio. Happy to share it if that is useful.

cargo test --release --lib passes (210 tests).

Not tested on Windows or Linux; the change is behind #[cfg(target_os = "macos")]. Only AirPods Pro were tested, no other Bluetooth headsets.

Screenshots/Videos (if applicable)

N/A

AI Assistance

• No AI was used in this PR
• AI was used (please describe below)

If AI was used:

• Tools used: Claude Code
• How extensively: Used for the investigation (writing CoreAudio probe clients, reading logs) and for drafting the patch and this description.

[cjpais]

I'm quite hesitant to pull this in. Mainly, what I'm concerned about is that it will make us like stealing the control from the AirPods too liberally and possibly prevent other devices from switching how Apple intended. I need more testing on this, and I need to think about it further as well

[mattdoran]

I know. It's so weird. I looked around for the "right" way to do it.

The current behaviour is broken. The APIs act like they are working but return nothing.

In using this for a few days it feels right. If you consciously make a decision to transcribe you expect your AirPods to handover to this and record.

You do not expect to talk for a bit and silently lose your transcription.

It's a tricky one.

[cjpais]

Yeah, I largely agree. The current behavior is also definitely broken with AirPods in particular

I am partially wondering whether or not this is something we can shove in advanced settings or debug settings so we can get kind of a broader range of feedback on without necessarily making it the default. For the most part I've been trying to avoid Bluetooth stuff generally speaking because it really needs a lot of time and focus to get correct, I think. So, yeah, curious your thoughts and feedback

I probably also need to try it with my AirPods in particular. I've just moved away from them for so long that I'm more or less used to just using the built-in MacBook microphone

[mattdoran]

Yeah, I think that's probably a reasonable compromise. Allowing people to opt in if they need it. But I feel it is the sort of thing that should "just work" and be enabled by default once it's been validated.

When the issue bites you and you get annoyed because you lose your transcription, it's not obvious what the cause is. Nor you'd need to go hunting in settings to make it work.

The setting name is gonna be fun to name! :/ "Force AirPods to switch to Mac to Transcribe" ??

I wonder if this happens with other multi-link Bluetooth devices? I don't have any to test.

[cjpais]

I agree, I've not really had a time to test this myself yet. I am wondering right now if you want to get this in, and maybe it would be easier for me to test to see if it should be the default. Is can we throw it as an experimental setting and go from there? At least it'll make it easier for me to merge because we don't need to think about it being a default if there's a way to opt out of this kind of behavior. Either a debug setting or an experimental setting is fine. And we can probably just call it like "AirPods Mode" for now lol

And largely, I'm asking for this because if we merge it, I can turn it on as the default in my version of Handy, even as I do development, just to get longer-term testing on it, and I will more easily be able to run it with my AirPods day to day for a few weeks and see how it goes so we can decide the default

[mattdoran]

Ok. Sounds good. Low commitment experiment that makes it easy to try (and I don’t have to run a custom build :) Want me to update the PR to have a “AirPods mode” experimental setting?

…

On Wed, 2 Sep 2026 at 12:22 pm, CJ Pais ***@***.***> wrote: *cjpais* left a comment (cjpais/Handy#1991) <#1991 (comment)> I agree, I've not really had a time to test this myself yet. I am wondering right now if you want to get this in, and maybe it would be easier for me to test to see if it should be the default. Is can we throw it as an experimental setting and go from there? At least it'll make it easier for me to merge because we don't need to think about it being a default if there's a way to opt out of this kind of behavior. Either a debug setting or an experimental setting is fine. And we can probably just call it like "AirPods Mode" for now lol — Reply to this email directly, view it on GitHub <#1991?email_source=notifications&email_token=AAENB4ZNEMXMN2ATSWNFSED5M577RA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJQGMZTQMBXHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5503380790>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAENB46NZVHCOSWSDDVYJBL5M577RAVCNFSNUABFKJSXA33TNF2G64TZHM4TGMJYHA4DMOJUHNEXG43VMU5TKMRXGQ4DQNJSGAZ2C5QC> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[cjpais]

Yeah, when you get a chance, it would be great. I would love to pull it in