Every Apple Music track at its own sample rate.

The first EQ engine was a hand-written biquad cascade in Swift, one sample at a time. Accurate, and about 10% of a CPU core for 16 bands of stereo at 192 kHz. Now the whole cascade runs on vDSP_biquadD from Accelerate, a block of up to 1,024 frames per call.

The single-precision path is just as fast and unusable: bass filters with a high Q have poles so close to the unit circle that Float coefficients cannot place them, and headphone presets are full of those filters. So the maths stays in Double. On the audio thread there are no locks and no allocations; a new preset arrives through one atomic swap, and two filter banks crossfade over 20 ms so an edit never clicks.

SyncHz uses the same RBJ cookbook filters and shelf conventions as both generators, so a preset means exactly what it meant on their side. The subtle part is the sample rate. Generators fit their filters at one rate, 44.1 kHz for AutoEq and 48 kHz for PEQdB, and the same numbers drift in the top octave when played at 96 or 192 kHz.

Each band is re-fitted at the rate that is playing to the response it had at its design rate, and split into two sections when one cannot follow. The fit is cached, so a rate change costs nothing you can hear.

The EQ uses the Core Audio process tap from macOS 14.4: a muted tap on Apple Music feeds a private aggregate device, the filters run there, and the result goes to your real output. A few lessons from getting it right:

• Tap the device's own stream, not the stereo mixdown. The mixdown is pinned to 48 kHz and resamples a 96 kHz track before you see it.
• Order the aggregate's inputs: the tap comes after the device's own inputs, or a DAC with a microphone input hands you silence.
• Declare audio input, even though nothing is recorded. Without it macOS denies the tap without a word.

With the EQ off, SyncHz is out of the signal path entirely.