MicLock stops a Mac microphone switch from making Bluetooth headphones sound muffled
The free utility needs Apple silicon and macOS 13 or later. A separate input device remains essential to its workaround.
Opening a meeting app can make perfectly good Bluetooth headphones sound as though the music has been placed on hold. The trigger can be the microphone selection. Your Mac starts using the headset for input, Bluetooth changes operating mode, and the soundtrack gets a telephone audition nobody requested.
Apple’s support page describes two Bluetooth modes: higher-quality listening, and simultaneous microphone input with lower-quality playback. Its immediate advice is to quit applications using the headset microphone. Apple also says to close Sound settings if that pane is open, then try reselecting the headphones through Control Center if the quality remains reduced.
That advice leaves a practical gap for somebody who needs the meeting and the music. MicLock’s answer is to keep another microphone as the default. A MacBook’s built-in microphone, a webcam input, or a USB audio interface can do the talking while the headphones keep doing the listening. The arrangement gives each device one job rather than demanding a miracle from the Bluetooth connection.
The project says it watches CoreAudio input changes and resolves a saved preference order: a primary microphone, three fallback choices, then a safe non-wireless input. Reconnecting headphones or waking a docked laptop can change the available devices. Remembering alternatives means the app has somewhere to go when the microphone you normally use is sitting unplugged on the desk.
Its maker is explicit that MicLock “does not alter Bluetooth codecs”. That is a useful boundary for an app with a name that sounds almost too neat. Anyone who needs the headset’s own microphone still faces the underlying tradeoff. A different default cannot make that microphone travel down a higher-quality connection by sheer optimism (Bluetooth has heard enough promises).
The 1.7.1 release is the package linked from the README. The documented requirements are Apple silicon and macOS 13 or later, with Developer ID signing and Apple notarization. Intel Mac owners should stop at that compatibility line rather than discover it after arranging an entire audio troubleshooting session.
The menu includes input levels and mute state, so checking that the chosen microphone actually hears you is part of the workflow. Sounding great to yourself while transmitting silence would be a particularly elaborate upgrade. The documentation says the local level samples are discarded and that the app makes no network calls; those are the developer’s privacy statements, not an independent audit.
The useful first experiment costs no new hardware: select a separate input and see whether playback recovers. If that fixes the problem but macOS keeps changing it back, MicLock automates the preference. If it does not, this particular fix has reached its limit, and buying another pair of headphones still has not explained the original failure.
Please hold the hold music.