What does "per-app audio" actually mean?

Per-app audio means giving one specific application its own volume and, optionally, its own output device, separate from what every other app on the Mac is doing. Turn Spotify down without touching a call in Zoom. Send a game to headphones while everything else stays on the speakers. It's control at the level of the app, not the whole machine.

The phrase shows up a lot on apps that claim to offer it, but rarely gets defined. It sounds like it should be obvious, and the practical result is simple enough, but the mechanism behind it is worth being precise about, because "per-app audio" gets used to describe a few genuinely different things depending on which app you're reading about.

The one thing everyone means by it

Strip away the implementation and per-app audio always comes down to the same shape: sound is grouped by which app produced it, not by which device it's playing through. Your Mac's volume keys and Control Center slider control one number, the system volume, which scales absolutely everything leaving the Mac at once. Per-app audio sits a layer underneath that. Each app gets its own level, which then gets combined with whatever the system volume happens to be set to.

Practically, that means three things become possible per app rather than machine-wide:

An independent volume. Turn one app down or up without moving the system volume, and without that app needing to build in its own in-app slider.

A mute that's scoped to one app. Silence a single notification-heavy app while everything else keeps playing normally.

An independent output. Send one app's sound to a specific speaker or pair of headphones while every other app keeps playing through whatever the Mac's default output is.

All three describe the same underlying idea: audio identified and controlled by its source app, rather than treated as one shared stream. Whether an app calls it "per-app volume," "per-app routing," or just "per-app audio," this is what it's referring to.

What it is not

Per-app audio is not an equaliser. It changes how loud an app is and where it goes, not the tone or frequency balance of what it sounds like. It's not an audio effect, so there's no reverb, compression, or noise gate attached to the idea. It's not recording or capture either: giving an app its own volume doesn't save what that app is playing to a file. And it's not the app-to-app virtual routing a DAW uses, where one app's output becomes another app's input for mixing or processing. Per-app audio, in the sense this post and Chorus use the term, is scoped to volume, mute, and output. Nothing more.

It's also worth separating from a related question people often ask alongside it: whether per-app audio covers microphones too, letting each app record from a different input. It doesn't, at least not in Chorus. Per-app audio here routes what an app plays out, not what it listens in on. Which microphone an app uses is a setting inside that app, or in System Settings' own input picker, not something per-app audio touches.

Why macOS needs an app to do this at all

None of this exists as a built-in setting on a Mac. There's no per-app row in System Settings' sound pane the way there's a per-app row in Windows' Volume Mixer. That's a genuine architectural gap in Core Audio, not an oversight, and we've written the full reasoning behind it separately in why can't a Mac set volume per app natively. This post is about what the capability means once an app adds it; that one is about why macOS doesn't have it already.

How Chorus actually does it

There are two real ways an app can deliver per-app audio on a Mac, and it's worth knowing which one you're getting. The older approach installs a virtual audio driver, a piece of system software that adds a new fake output device, then leans on you to point the app at that device manually and adjust the device's volume instead of the app's. We've covered how that works, and what it costs you, in what is a virtual audio driver.

Chorus doesn't use a driver. It uses Core Audio Process Taps, a capability Apple added to macOS in version 14.4, which lets a permitted app read another running app's live audio stream directly, mute that app's normal output, and re-render the captured audio to whichever real device you've chosen, with your chosen volume applied. It's a user-space API gated behind a one-time permission prompt, similar to granting screen recording access, not a kernel extension and not a driver you have to install and maintain alongside macOS updates.

One boundary worth stating plainly: Chorus's per-app audio routes outputs, an app's sound as it leaves the Mac, not inputs. There's no per-app microphone picker, and per-app audio doesn't touch how an app records. If an app is left at its default volume and default output, Chorus doesn't tap it at all, so most of what's playing on your Mac at any moment isn't being intercepted in any way, only the apps you've actually chosen to set a different volume or output for.

For the full technical detail on the framework, see Apple's own Core Audio developer documentation.

Frequently asked questions