Two displays, one stereo pair.

Two identical-looking displays sitting side by side, each with six speakers in it. Played as two separate devices they each produce their own stereo image, about two feet apart, which sounds like two radios playing the same song. What I wanted was obvious: the left panel is the left channel, the right panel is the right channel, one wide stereo pair.

macOS does not have a checkbox for this. The Sound settings panel lets you pick one output device. Two displays are two devices.

Audio MIDI Setup can combine devices two ways, and only one of them works here.

A Multi-Output Device mirrors the same signal to everything in it. Both displays would play full stereo. That's for playing the same thing in two rooms, not for splitting channels.

An Aggregate Device concatenates the channels instead. Each Studio Display presents eight output channels, so the aggregate has sixteen: one to eight is the first display, nine to sixteen is the second. Then "Configure Speakers" lets you say which of those sixteen is Left and which is Right.

Each display takes an eight channel feed: front left, front right, front centre, LFE, back pair, top pair. The stereo mapping only lets you pick one of those per side, so the question is which one makes a whole display sing.

Front centre seemed right. It's the middle, it should engage the whole array. It sounded terrible. Not quiet, just vague, like the sound was coming from the general direction of the desk rather than from anywhere. My guess is that feeding a display its centre channel makes its internal processing spread the signal across all six drivers, so neither panel behaves like a point source and there's nothing for a stereo image to hang on.

Front left on the left display and front right on the right display images far better. Same speakers, same volume, completely different sense of where things are.

I'd actually tried the corner channels early on and dismissed them as thin. That test was run while left and right were still swapped, so it was never a fair comparison. Worth re-running experiments after you fix the thing that was confounding them.

The moment the aggregate became the output, the volume keys stopped working and the menu bar slider went grey. macOS doesn't provide volume control for aggregate devices at all. Not a bug, just not implemented.

So the setup needed a small app: a menu bar item that writes volume to both displays at once through CoreAudio, keeping them locked to the same value, and intercepts the volume keys so they behave normally.

It grew from there. It now also carries brightness, True Tone, Night Shift and auto-brightness for both panels together, and it selects the aggregate automatically when the displays reappear after undocking.

With everything mapped correctly it still sounded smeared. Centred vocals wouldn't lock between the screens, and on video it was an audible echo between left and right.

CoreAudio reports each device's latency, and the two displays were nowhere near each other:

A 1805 frame gap. 37.6 milliseconds, which is far past the point where two sounds stop fusing into one and start sounding like an echo.

An aggregate device stores a per-member latency-out value for exactly this, so the fix looked like arithmetic: add 1805 frames to the fast display and they line up.

It sounded worse. Noticeably worse.

That value doesn't delay a device. It declares that a device has extra latency, so the system compensates by sending its audio earlier. I'd applied it to the display that was already early and doubled the error. Same number, wrong display.

Moving the 1805 frames to the slow display helped a lot but wasn't right either. So I stopped reasoning about it and built a small script that steps through candidate offsets, playing a click burst at each one, and listened.

The measurement said 1805. The right answer was 800. macOS compensates for part of the gap on its own, just not all of it, and no amount of reading numbers would have told me how much. The only reason 800 is trustworthy is that it beat its neighbours on both sides, which is the difference between a minimum and the edge of a range you happened to stop at.

Both displays run off one Thunderbolt port, chained. So the obvious story was that the downstream display picks up latency going through the first one's controller, and the fix is to give each display its own port.

I was about to recommend rearranging the desk when I checked the USB tree properly. Only the newer display exposes Desk View cameras, which identifies it, and its speaker interface number matches one of the two audio device IDs. The newer display is the one plugged straight into the Mac. The 2022 display is the one hanging off the back of it.

The downstream display is the fast one. The chain isn't the cause. These are two different generations of hardware and the newer one simply has slower audio, presumably because it does more processing before anything reaches a speaker. Re-cabling would have cost dock bandwidth and fixed nothing.

The tuning lives in coreaudiod's own settings file rather than anywhere I control, which turned out to be good news: unplug the dock, plug it back in, and it all comes back without intervention. I tested that rather than assuming it.

The whole thing is two displays doing something Apple never advertised they could do, held together by about four hundred lines of Swift and a number I could only find by listening.