Will Your AI Notetaker Keep Recording If You Switch to AirPods Mid-Call?

Two streams, and a headset change can break either one

A notetaker that joins the call as a bot hears the meeting from the platform's side, so your headphones make no difference to it. A notetaker that runs on your Mac with no bot records two separate things: your microphone, which carries you, and your computer's audio output, which carries everyone else. Every time you put in AirPods, take them out, plug into a dock or let a headset battery die, macOS moves one or both of those streams to a different device.

The failure is quiet. The recording indicator keeps running, the app shows a timer, and you find out afterwards that the transcript holds only your side, or only theirs, from the minute you switched. Wispr Flow's help page says it plainly: "an active recording does not mean both sources are working."

Almost every botless notetaker handles AirPods at the start of a call. The useful question when you evaluate one is what it does to each stream when the device changes halfway through.

Your voice: which microphone the notetaker follows

Most desktop notetakers record whatever macOS has set as the default input. Wispr Flow's troubleshooting doc says its notetaker uses the operating system default input, has no in app device picker, and that changing the default during a recording switches capture to the new device after a brief microphone gap. Granola does something more careful: its Auto setting follows your meeting app's microphone when a meeting app is open and falls back to the system default otherwise, and you can pick a microphone by hand from the transcript window.

That difference matters in one common setup. Zoom and Teams both let you choose a microphone inside the app instead of following the system. If Zoom is using your AirPods microphone while macOS still has the built in microphone as its default, a notetaker that follows the system default records you through the laptop across the desk. You will still appear in the transcript, quieter and with more room noise, and the notes about what you said get worse.

The opposite case is worse. If the default input points at a microphone that is unplugged, muted or sitting in a drawer, your side goes silent. Wispr Flow shows a warning after a minute without microphone audio. Ask any tool you are considering whether it warns you, and how long it waits.

Their voices: the output side is where switching hurts most

Other participants reach the notetaker through system audio, the sound your Mac is playing. When you move playback from the laptop speakers to AirPods, the tool has to keep capturing what the meeting app plays even though it now plays somewhere else.

Not every capture design survives that. While building Driffle's capture, an approach that tied system audio capture to the output device's clock produced nothing at all with AirPods as the output: on macOS 26.2 the measured peak level was 0.000000 against 1.017493 for a capture that runs on its own clock, on the same machine at the same moment. The far side of the meeting was simply missing. Docks have their own version of this. Wispr Flow's doc warns that USB-C hubs or docks with audio devices can leave other participants' audio silent, and its fix is to reconnect the hub or stop and start a new recording.

This is why a one sided transcript is usually a device problem or a permission problem, and both look the same from inside the meeting. The Granola doc suggests a simple check: open the transcript and see which side is missing, since your microphone and the meeting's audio are shown as separate bubbles.

The trade you make when the headset is also the microphone

Granola's doc names a limitation of many Bluetooth headsets: they cannot play high quality audio and use their own microphone at the same time, so when the headset microphone is in use the headset drops to a lower quality mode. You hear this as everyone on the call suddenly sounding like a phone line.

For a notetaker it matters twice. If your meeting app is already using the AirPods microphone, the headset is in that mode anyway and the notetaker changes nothing. If the call is using the laptop microphone and the notetaker opens the AirPods microphone, it can drag the headset into the lower quality mode on its own, which degrades both what you hear and the audio being transcribed. Granola's suggested fix is to set the laptop's built in microphone as Granola's microphone so the headset stays on high quality output.

What Driffle does when you switch, and what it does not do yet

Driffle records your voice from whatever macOS has set as the default input, including AirPods. An earlier build preferred the built in microphone whenever the default was a Bluetooth headset, to keep the headset in its high quality mode. In a live test that meant the microphone level read zero for an entire session while the person spoke into their AirPods, so the rule was changed to trust the default you or macOS chose. If no default is usable, Driffle falls back to the built in microphone, then a wired or USB microphone, then any Bluetooth one.

During a recording it watches for two changes, a new default input and a device being added or removed. A Bluetooth headset connecting fires a burst of these, six within 130 milliseconds in one observed case, while the link is still settling, so Driffle waits until half a second after the last one before rebuilding the microphone on the new device. After one AirPods out and back in test the microphone stream settled at half its expected rate and produced no transcript; Driffle now checks the measured rate every second and rebuilds the microphone after three bad seconds in a row.

Everyone else's audio comes from one system audio capture across all apps that runs on its own clock, so moving playback to AirPods or back does not interrupt it. If your microphone is live but no system audio arrives while other apps are playing sound, Driffle shows a banner during the meeting saying only your microphone is being recorded and the far side will be missing.

The limits are real. Driffle has no in app microphone picker, so if your meeting app is pinned to a different microphone than the macOS default, Driffle hears you through the default one. There is no warning yet when only your microphone goes silent; the warning covers the far side. Driffle runs on Macs with Apple Silicon only, and transcription happens in the cloud, not on the device.

Four switches to try on a test call

Do this once with a colleague who has agreed to be recorded, before you rely on any notetaker for a call that matters. Start the call on laptop speakers and the built in microphone, and talk the whole time so there is something to transcribe on both sides.

Afterwards, read the transcript around each switch. You are looking for a gap on either side, lines from the other person attributed to you, and whether the app told you anything while it was happening. A tool that loses a side silently will do it again on a call you cannot repeat.

• Two minutes in, put your AirPods in and let macOS switch to them for both playback and microphone.
• Two minutes later, take one AirPod out, then the other, so the Mac falls back to its own speakers and microphone.
• If you use a desk dock or USB-C hub with audio, unplug it and plug it back in mid sentence.
• Set the meeting app's microphone to something other than the macOS default, and check which microphone your voice was actually recorded through.

Pick for the way you actually work

If you take every call at one desk with one headset, device handling barely matters. If your day moves between a dock, AirPods and a laptop on a kitchen table, it decides whether you get notes on both halves of the conversation, and it is worth ten minutes of testing before you commit.

If you want a Mac notetaker with no bot that follows your device changes during a call, Driffle is at driffle.ai/download.