You are on a video call, you switch to Music for a second, and for a fraction of a beat everything mutes or clicks. Or you close the lid, open the Mac an hour later, and the first few seconds of whatever plays sound stuttered before settling down. Neither is a bug in the app you were using. It is the output device changing its sample rate underneath you, and macOS briefly catching up.
Why the rate keeps moving
Every audio output on macOS, built-in speakers, headphones, a USB interface, has one property called its nominal sample rate. You can see it in Audio MIDI Setup, in the Format menu next to the device. At any moment, the device is running at exactly one of the rates it supports, not several at once.
macOS mixes everything your apps are playing into a single stream before it reaches that device. If a track is sourced at 44.1 kHz and your call is running at 48 kHz, one of them has to be converted, because the hardware clock can only tick at one speed. Most of the time that conversion is invisible: the system’s mixer resamples on the fly and you never notice.
The visible switch happens with hardware that supports several native rates, mainly USB audio interfaces and DACs, and with apps that ask for direct, unmixed access to get a bit-perfect signal instead of a resampled one. High-fidelity players and some pro audio tools do this on purpose, because it lets the interface’s own converter handle the rate instead of a software one. When that happens, the device’s clock itself moves to match the new source, and you hear the brief mute while it reconfigures. Built-in Mac output does not usually behave this way, it tends to expose a small fixed set of rates without that exclusive-access negotiation.
What the conversion actually costs
Converting between 44.1 and 48 kHz is not a clean multiple, unlike doubling 44.1 to 88.2. Reduced to a ratio it is 147:160, which needs a proper filter to avoid artifacts near the top of the audible range. macOS’s own converter handles this well in practice, so sound quality is rarely something you can point to.
The real cost is timing, not tone. Video call software, most of it built on the same kind of real-time audio pipeline, tends to settle on 48 kHz internally regardless of what any other app on the Mac is doing. Music libraries, meanwhile, are full of tracks sourced from CD-era 44.1 kHz masters. Every time you jump between the two, something has to give, and on hardware that supports rate switching, the device sometimes resolves that by moving its own clock rather than leaving the whole job to software.
Why sleep and device changes turn a mismatch into a dropout
A one-time resampling cost is cheap. What actually produces a dropout is renegotiation. When your Mac wakes from sleep, the audio system reconnects to the hardware from scratch, and every device has to report its current format again. If an app’s audio engine was primed for the format that existed before sleep, and the device comes back reporting something else, that engine has to reinitialize before it can push audio again. Until it does, buffers run dry, and you get the stutter.
Switching output devices causes the same kind of gap for a different reason. Moving from built-in speakers to a Bluetooth headset to a USB interface means each device brings its own supported rate and its own idea of what counts as current. A Bluetooth headset’s call microphone path is often tuned for speech and can behave differently from its own music playback path, so switching between a call and normal listening on the same headset can retrigger the same renegotiation you’d get from unplugging a cable.
Where a system-wide driver like ZonaReq fits
Anything that sits in the audio path between your apps and the speakers inherits this exact problem, and a system-wide equalizer is no exception. ZonaReq’s driver captures the mix macOS hands it and has to send audio back out at whatever rate the real output device is actually running, not a rate it assumed once when it started up. Early on, a mismatch between an internal capture stage and the live output rate produced the same kind of choppiness described above, and the fix was to read the device’s current rate continuously and recompute the conversion from that, instead of hardcoding one. It is the same mechanism this whole piece describes, just one layer further down the chain.
That also means pinning a rate in Audio MIDI Setup helps ZonaReq exactly as much as it helps any other app, no more and no less. There is no special setting inside ZonaReq that substitutes for getting the system-level rate settled, because the renegotiation happens below any app, in coreaudiod and the driver stack, before ZonaReq or anything else ever sees the audio.
What to actually set in Audio MIDI Setup
Open Audio MIDI Setup, in Applications/Utilities, and select your output device on the left. If the Format menu only lists one rate, there is nothing to change, and none of this applies to your setup. If it lists several, which is common on USB interfaces and on aggregate devices built for multi-output, pick the one that matches what you do most: 48 kHz if your day is mostly calls and video, 44.1 kHz if you are mixing or listening to music sourced from older masters.
Pinning a rate does not remove resampling. Anything at the rate you did not choose still gets converted. What it removes is the renegotiation itself, since the device’s clock no longer has a reason to move. That is usually what actually fixes a dropout that shows up after sleep or after switching devices, because the device already knows its own rate and only has to return to it, not decide on a new one. Restart any app that was already open when you change the format, it cached the old one.
If you never hear the click, the stutter, or the dropout, leave the setting on automatic. This is a fix for a specific, audible symptom, not a change worth making for its own sake.