How Sample Rate and Buffer Size Affect Spatial Audio
Understand latency, CPU load, device compatibility, resampling, dropouts, and practical Mac settings for real-time spatial DSP.
Sample rate determines how many audio samples are processed per second; buffer size determines how many samples are handled at once. Smaller buffers reduce latency but increase CPU pressure and dropout risk. For most Mac listening, 48 kHz with a moderate 128- or 256-sample buffer is a practical starting point.
Key takeaways
- Buffer latency is approximately buffer samples divided by sample rate, per buffered stage.
- Higher sample rates increase processing cost and do not automatically improve spatial accuracy.
- Wireless transport usually dominates total latency, not the DSP buffer.
- Repeated rate switching causes more audible trouble than steady resampling.
- Clicks usually mean the real-time path cannot finish before the next buffer arrives.
What the sample rate changes
At 48 kHz, the engine processes 48,000 samples per channel each second. A 64-channel or convolution-heavy system therefore performs substantially more work than stereo playback. Raising the rate to 96 kHz roughly doubles the sample workload before considering longer filters or conversion stages.
Many films, games, and system-audio paths use 48 kHz, making it a natural default. Music libraries may contain 44.1, 48, 96, or higher rates. A stable real-time conversion is preferable to repeated device resets for every source track.
There is a specific reason to prefer steady conversion over automatic switching on a system-wide path. Changing the hardware rate requires Core Audio to reconfigure the device, which typically produces a brief interruption. On a machine playing music, notification sounds, and video in quick succession, frequent renegotiation is more disruptive in practice than a well-implemented resampler running continuously.
What the buffer changes
A 128-sample buffer at 48 kHz represents about 2.7 milliseconds of audio for one buffer. Actual end-to-end latency includes input and output safety buffers, wireless transport, convolution strategy, and any additional applications. Cutting the buffer in half reduces one component of latency but gives the CPU half as much time to finish each block.
The relationship is worth stating explicitly because it explains why smaller is not simply better. Halving the buffer halves the time available to complete the same work per block while doubling how often that work must be scheduled. A system comfortably stable at 256 samples can drop out at 64 not because the total processing increased but because the deadline became too tight to meet reliably under load.
Where the latency actually comes from
Users often adjust the buffer when the DSP stage is not the dominant term. On a wireless headphone the transport buffer is typically far larger than any reasonable processing buffer, so reducing the latter changes the total very little while making the system less stable.
The productive order is to remove the largest contributor first. If timing matters, use a wired connection before touching buffer settings. Then consider the source application's own buffering, which for some players is substantial and independent of the system. Only after those does the processing buffer become the term worth optimising.
Choose settings by use
Music and movies tolerate more latency than live monitoring or interactive instruments. Games benefit from a moderate setting, while wireless headphones often add more transport latency than the DSP buffer. Start at 128 or 256 samples, then reduce only if interaction feels delayed and the system remains stable.
For listening, latency is essentially irrelevant. Audio and video are synchronised by the player, which compensates for a reported output delay, so a large buffer costs nothing audible. Choosing a small buffer for music playback trades real stability for a benefit that does not exist.
- Music and film: 256 samples or larger, stability first.
- Games: 128 to 256, and prefer a wired connection.
- Live monitoring: as small as the system sustains without dropouts.
- Anything wireless: fix the transport before adjusting the buffer.
Diagnose dropouts
If clicks appear, increase the buffer, close heavy background tasks, verify the physical device’s rate, and test a wired output. If audio becomes slow or pitch-shifted, the source and device may disagree about rate rather than merely suffer high CPU load. Return every device to one known rate before investigating the spatial filters.
The pattern of the artefact narrows the cause. Clicks under heavy load point at the buffer being too small for the work. Clicks at a regular interval regardless of load suggest a clocking mismatch between devices rather than a processing shortfall. A single click when playback starts or when the source changes rate is usually device reconfiguration and is not a fault. Audio at the wrong pitch or speed is always a rate disagreement, never CPU load.
Frequently asked questions
Does 96 kHz improve head tracking?
Not by itself. Tracking update quality depends on sensor and renderer timing; higher audio rate mainly increases audio processing workload.
What buffer should I use with AirPods?
Start with the application default. Bluetooth transport usually dominates latency, so extremely small DSP buffers may add CPU risk without a meaningful perceived benefit.
Should I let the sample rate follow each track?
On a system-wide path, usually not. Every change requires the device to reconfigure, which interrupts audio. A fixed rate with steady conversion is less disruptive than frequent renegotiation.
Does resampling degrade sound quality?
A competent modern resampler introduces artefacts far below what is audible in normal listening. The practical arguments concern CPU cost and avoiding device reconfiguration, not fidelity.
Why do I get clicks at a regular interval even when the Mac is idle?
That pattern suggests a clocking mismatch between devices rather than insufficient CPU time. Check that every device in the chain is set to the same rate and that nothing is running as an aggregate with drift compensation disabled.
Will a smaller buffer make my music sound better?
No. Players synchronise audio and video using the reported output delay, so latency is inaudible during playback. A small buffer trades stability for a benefit that does not exist for listening.