How macOS actually chooses your audio device

The default device

At any moment macOS has exactly one default output device and one default input device. When an app plays a sound it does not choose a speaker — it hands the audio to the system, and the system sends it to whatever the default currently is.

This is why a single wrong switch moves everything at once. Your music, your meeting and your notification sounds are all following the same pointer.

The rule

macOS has one rule for choosing your audio device: whatever connected most recently wins. There is no notion of preference, and no way to tell it that one device matters more than another.

Every familiar annoyance follows from it: AirPods waking in a drawer, a dock moving audio to a monitor, unplugging headphones blasting the built-in speakers. None of these are failures. They are the rule working as designed.

The "automatic switching" people go looking for in System Settings is this same behaviour, not a separate feature that can be turned off in favour of something smarter.

What third-party apps can and cannot do

Core Audio lets an app list the audio devices, read which one is currently the default, change the default, and be notified when any of that changes. Those are public, long-standing calls, and — importantly — they need no permission at all. No prompt, no privacy pane, no entitlement.

That is the whole basis for priority-based switching: an app can watch for device changes and immediately set the default back to the one you actually wanted.

What no app can do is prevent another application from claiming a device. If an app opens its own audio session and demands a specific device, it gets it. A switcher sits above that layer: it can notice and switch back, but it cannot block the change. Be sceptical of any tool that claims otherwise.

Why doing it well is harder than it sounds

Real hardware reports a single physical plug several times, so anything reacting to the first notification will flap. A short debounce before acting is necessary, which is why good switching is fast rather than instantaneous.

It also has to know when to stop. If you pick a device by hand and software immediately overrides you, it feels possessed. Any switcher worth running stands down for a while after a manual choice, and gives up entirely if it finds itself switching repeatedly in a short window.

macOS 26 audio bugs worth knowing about

macOS 26.0 shipped with real audio problems, since fixed. Audio capture failed from FaceTime and the Phone app in many setups, and failed when a secondary output device ran at a different sample rate from the system default. A separate bug made Safari audio skip or click when the default output ran at 44.1 kHz.

All three were corrected in macOS 26.1, which is why anyone doing anything serious with Mac audio should be on 26.1 or later rather than 26.0.

The menu-bar Sound control was also unreliable for a period, to the point that people wrote command-line scripts to switch outputs instead. If your Sound menu has felt flaky, that was not imagination.

The missing feature

What macOS has never had is a notion of preference — an ordered list saying use this if it is available, otherwise that. As of macOS 26.6 it still does not, which is the gap Tunestack exists to fill.