Skip to main contentOctopus Think
Published on
26 January 2022

How we fixed the mic on macOS Monterey

When a bug in macOS meant Mic Drop stopped working with Bluetooth headphones, we needed to come up with a fix. The solution was far stranger than we expected.

It’s August, and I’ve been testing the new Monterey beta release. I’m in the middle of a meeting. Everything seems great so far. Promising! Then Sarah turns on the coffee grinder in the background. I toggle the mute—and my meeting goes silent. Uh-oh.

It turns out Monterey has a bug where Bluetooth input and output channels are linked, meaning that if you mute your Bluetooth device’s microphone, all audio cuts out. We make a mic-muting appExternal link, so this is pretty bad news for us. We reported the issue to Apple straight away, figuring they’d fix it before Monterey was released to the public.

Nearly six months later: 🦗🦗🦗. Apple hasn’t even acknowledged the issue we filed yet, and multiple versions of Monterey have been released to the public with the same bug. It affects every app that controls the microphone, including Apple’s own apps. 😩

Obviously, we couldn’t count on Apple to fix the problem. We had to do something ourselves.

Like anything involving audio on macOS: it wasn’t pretty.

Why Bluetooth headphones can’t be muted anymore

Many Bluetooth headphones, including all of Apple’s own AirPods and Beats headphones, come with input (tiny microphone) and output (tiny speakers) channels. This is how you can have a phone call or Zoom meeting using your AirPods.

In every previous versions of macOS, you could mute these devices separately. If you muted your speaker, your mic still worked. If an app—like Mic Drop—muted your microphone, you could still hear the audio in your meeting.

This no longer works in macOS Monterey! Now the input and output channels “mute” settings are linked. You can see this in action using Apple’s own Audio Devices app.

Screen recording of the Audio MIDI Setup app on macOS, muting a Bluetooth device's microphone, then switching to the Bluetooth device's output showing that it is linked and muted.

Why this app is still called “Audio MIDI Setup” is anyone's guess.

Muting or unmuting either channel also mutes or unmutes the other. This is bonkers—and very clearly a bug—because it means that you can’t mute your input without all audio cutting out. Not ideal if you’re trying to mute yourself in a meeting but, you know, still want to hear what other people are saying. (It’s possibly ideal if you’re tired of hearing your co-workers though.)

Our awful awesome workaround

This is a bug deep in the operating system and there’s no way around it. Our fix? We just ignore Bluetooth entirely and force users’ machines to use the built-in microphones on their Mac instead.

This may sound bananas, but it’s actually the most reliable solution we could find, after several long weekends spent building more and more elaborate Rube Goldberg machines just to get the damn mic to mute. Most Macs have built-in microphones that are actually quite good, and those that don’t (eg. the Mac mini & Mac Pro) will likely have a webcam attached. If we can’t find a mic we can mute (hopefully this won’t happen often), we show an error:

Trying everything to see what works

If you’re a technical Mac user and know anything about audio apps on macOS, you might be wondering why we went with such a bananas solution. It wasn’t our first choice and we actually resisted shipping this fix, hoping Apple would fix the bug. But by the time of Monterey 12.2 with no fix in sight, we had to do something. Here’s all the the things we tried that didn’t work:

Attempt #1: Aggregate audio devices to route the Bluetooth audio through

This was something we had been thinking about for a long time, even before the Bluetooth woes. Some devices don’t work well with Mic DropExternal link because macOS can’t mute them directly.

A workaround is to create a virtual device using an app like LoopbackExternal link. We tried creating a basic macOS aggregate device with CoreAudio APIs that we could pass Bluetooth mic audio into, but these basic aggregate devices couldn’t be muted easily and changing the device we routed through it dynamically during a meeting was buggy.

This also would’ve meant we need to add a UI to select which device(s) route through Mic Drop. With all of these issues and the worry that aggregate device creation might not even be accepted by the Mac App Store, so we ditched this approach.

Attempt #2: Switching devices on-the-fly when muting

This didn’t work predictably with a lot of apps. Google Meet, for instance, would ignore/override a switch made while the app was open. Other apps would react oddly to the device change or alert the user. And any time we did this there would be a notable audio cut-out while the Bluetooth headphones switched from “listening” mode to “talking + listening” mode.

You could lose a second or more of audio depending on the device, so this was a bad solution for meetings—which is the main use-case for Mic Drop.

Attempt #3: Okay, so… just fix it by unmuting the audio output?

For Bluetooth devices: unmuting the audio output unmutes the input, so people are gonna hear you slurping your coffee as soon as we change any Bluetooth audio settings. Bluetooth devices are off-limits for now.

Attempt… #1736: It works!

In the end, ignoring Bluetooth microphones is the only way we can reliably use Bluetooth headphones and Mic Drop together (until Apple fixes this problem). But our solution is a bit more intricate than just ignoring Bluetooth devices.

Because we can no longer mute Bluetooth mics, we have to make sure they aren’t ever the default device. Mic Drop now detects any time your default input is set to a Bluetooth device. If this happens and have a non-Bluetooth device we can use, we automatically switch your input to the compatible mic. Then we mute every device except your Bluetooth devices so you can still hear audio in your headphones but mute yourself globally.

Of course, computers are weird and allow specific apps to override your default settings. You might set your built-in microphone as your default input, but Zoom can be set to still use your AirPods as its input. Some apps (like Google Meet) even notice that your default input + output devices aren’t the same device and will ignore your system’s default—using your AirPods as the input anyway.

Sometimes Google Meet will actually override your system defaults when this happens, so we had to do our best to protect users from having a Bluetooth mic leak sound into their meeting.

This isn’t great, because we really, really don’t want users to think they’re muted when they’re not. To get around this, we “claim” the microphone audio of Bluetooth devices as best we can, so other apps can’t use it while Mic Drop is running. This means apps like Google Meet are less likely to get audio from Bluetooth.

Bonkers but beautiful

We’ve been testing this fix in our own meetings for the last few weeks, and it works surprisingly well. It’s a bit of a wild solution, and for our three “Mac Pro + AirPods”-only users in meetings it won’t work, but we think for the majority of users, this will magically solve the problem.

If Apple ever fixes the issue on their end, we’ll revert back to the original behaviour.

But for now, we’re just delighted that we can use our AirPods again.

Octopus Think

Octopus Think is a design & development duo based in Scotland and Portugal. We build smart, inclusive, usable digital products that make people’s lives better.

Sign up for quarterly updates

Copyright © 2022 Octopus Think Ltd.UK Registered Company No. 11747595External linkVAT ID: GB324954685Report an issueExternal link with this site