Audio delayed after routing an app on Mac? What to check

When an app's sound lags after you route it to a different output on a Mac, the delay is almost always in the destination or the plumbing, not the app. A Bluetooth output adds roughly 100-200 ms on its own, an Aggregate or Multi-Output Device without drift correction slowly slips out of sync, and each extra virtual-cable hop adds another buffer. Check those three first, in that order.

The frustrating part is that routing "worked" — the audio is coming out of the right device — so it's tempting to blame the app or reinstall something. Don't. Audio delay on a Mac follows a small number of physical and clock-related rules, and once you know them you can usually spot the cause in under a minute. Here's the checklist, roughly ordered by how often each one is the real culprit.

First, describe the delay — it tells you the cause

Two very different problems both get called "delay," and they have different fixes:

• A fixed offset. The sound is consistently a fraction of a second behind the video or your keypresses, and it stays that far behind. This is latency — buffering somewhere in the path. Almost always the output device.
• A growing offset. It starts fine and creeps further out of sync the longer it plays, until lip-sync is visibly wrong after an hour. This is clock drift — two audio devices running on slightly different clocks. Almost always an aggregate/multi-output setup.

Figure out which one you have. It points you straight at the section below that matters.

Check 1 — Is the output Bluetooth? (the most common cause)

If you routed the app to AirPods, a Bluetooth headset, or a Bluetooth speaker, that is very likely your whole answer. Bluetooth audio is buffered by design, so it carries unavoidable delay. AAC to AirPods typically measures somewhere around 100-200 ms depending on the device and conditions — fine for music, plainly late against video, and enough to make a game feel off.

It gets worse in one specific case. The moment the same Bluetooth headset is also used as a microphone — you join a call, or an app grabs the mic — macOS drops to a call-oriented profile, and output latency can climb to roughly 200-300 ms while quality drops too. So "audio is fine until I'm on a call" is a Bluetooth-profile story, not a routing bug. We wrote about the same profile trap in the context of one app going quiet over Bluetooth in why Bluetooth audio is quiet for just one app on Mac.

No software removes Bluetooth latency — it's the transport, not your Mac. The fix is to route anything lip-sync-sensitive (video calls, a movie, a game) to a wired or the built-in output, and keep Bluetooth for music and podcasts where a fraction of a second doesn't matter.

Check 2 — Are you using an Aggregate or Multi-Output Device?

If your routing relies on an Aggregate Device or a Multi-Output Device (built in Audio MIDI Setup, often to push one app to two outputs at once), and the delay grows over time, this is clock drift. Each physical device has its own crystal clock, and if the combined device isn't correcting for the difference, the streams slide apart — a few milliseconds a minute becomes seconds after a couple of hours.

The fix inside Audio MIDI Setup:

• Set the clock source (the "primary" device) to your most stable output — usually an external interface if you have one, otherwise built-in output.
• Enable Drift Correction on every device in the aggregate except the clock source. This resamples the others to keep them locked.
• Make sure every device in the aggregate is set to the same sample rate (see Check 4).

Drift correction fixes the creep, but it is a workaround for a setup you may not need. If your actual goal is just "this app out of that device," a per-app router points each app straight at a real output with no aggregate to hand-tune — see per-app audio output on Mac without Loopback or virtual cables.

Check 3 — How many hops is the audio taking?

Virtual audio drivers like BlackHole are effectively zero-latency on their own, but they don't move sound to a speaker — they hand it to another app, which then hands it to a real device. Each stage in that chain (app → virtual device → routing/mixer app → output) adds its own buffer. A two- or three-hop path built out of virtual cables can stack up a noticeable offset even when no single piece is slow.

Count the hops. If the audio is passing through a virtual cable into a second app before it reaches your headphones, collapse the chain: fewer stages, less buffering. The lowest-latency routing is the one that takes the app's audio to a real output device directly, without a middle app in between.

Check 4 — Sample-rate mismatch

If the app is producing 48 kHz, a virtual device is set to 44.1 kHz, and the output is something else again, macOS has to resample on the fly at every mismatch. That adds latency and, in an aggregate, feeds the drift problem. Open Audio MIDI Setup and set the app's route, any virtual device in the path, and the final output to the same sample rate — 48 kHz is a safe default for most setups. Matching rates end-to-end removes a whole class of both delay and crackle.

Check 5 — The routing tool's own buffer

Some routing and mixing tools expose a buffer size or I/O safety-offset setting. A large buffer is stable but slow; a small one is snappy but can glitch on a busy Mac. If your tool has this control and you've ruled out the causes above, nudge the buffer down a step and listen for dropouts. This matters most for live monitoring and games; for watching video it rarely moves the needle compared to Bluetooth.

The setup that avoids most of this

Most routing delay on a Mac is self-inflicted — it comes from the machinery people build to route audio in the first place: aggregate devices that need drift correction, virtual cables chained through a second app, sample rates that don't match. Strip the machinery away and most of the list disappears with it.

That's the approach Fader takes. It routes each app to its own output device at the OS level, without an aggregate you have to configure and without a virtual cable feeding a second app. Fewer stages in the path means fewer places for delay to hide. And because switching an app's output is one action, when a destination is the problem — a video call stuck on AirPods, say — you can move that app back to the built-in output in a second and get sync back, without unplugging anything or rebuilding a device. More on that in how to send an app's audio to a different output on Mac.

To be clear about the honest limit: no app can make Bluetooth low-latency — that delay lives in the wireless link, and every tool inherits it equally. What good routing avoids is the added delay from aggregates, drift, and cable chains. That part is very much fixable.

Bottom line

Audio that lags after you route an app on a Mac is a plumbing problem, not an app problem. Ask whether the delay is fixed or growing: a fixed offset is almost always the output device, and if it's Bluetooth, that's your answer — route lip-sync-sensitive apps to a wired or built-in output. A growing offset is clock drift from an aggregate or multi-output device; enable drift correction and set a stable clock source, or skip the aggregate entirely by routing per app. Match your sample rates, cut any extra virtual hops, and the delay you can control goes away.