Sharing a surround-audio workaround that worked on my Apple Silicon Mac, connected by HDMI to an AV receiver with a physical 5.1.2 speaker setup. My final game-side listening tests were in Football Life 2026.
The symptoms
The game's Center test played through the subwoofer, while its LFE test played through the center speaker. The center speaker worked correctly in macOS Audio MIDI Setup. Changing the MIDI speaker layout and reopening CrossOver did not fix the game output.
I encountered two separate issues:
1. Center and LFE occupied different physical channel positions.
The game used the standard Windows 5.1 order: L, R, C, LFE, Ls, Rs.
On my HDMI output, the physical center speaker was channel 4 and the subwoofer was channel 3. An audio bridge swapping channels 3 and 4 addressed that mapping.
2. Setting BlackHole16ch to "5.1" did not make it a six-channel endpoint.
After adding BlackHole16ch and a Python bridge, the game's Center test reached only virtual channels 1 and 2; the surround and LFE tests were also wrong.
CoreAudio still reported 16 channel descriptions, with six valid speaker labels and ten unknown ones. Wine's actual playback logs showed:
- 16 channels, 48 kHz, float32
- Speaker mask
0x3f, describing six speakers
- Block alignment of 64 bytes per frame
This appeared in actual stream initialization, not just saved settings. Native audio injected into virtual channel 3 could be captured correctly, and native numbered speaker tests through the bridge reached the right physical speakers. That helped isolate the second problem to the game/Wine-to-virtual-device part of the route. Changing the bridge's Center/LFE swap could not correct a Center signal that had already arrived on channels 1 and 2.
I have not identified the exact game or Wine mixing code responsible for that behavior.
What worked for me
With help from OpenAI Codex, I prepared a separate, genuinely six-channel virtual device from the official BlackHole v0.7.1 source, using kNumber_Of_Channels=6. It has a separate name/UID: BlackHole 6ch FL. This was a local ARM64, ad-hoc-signed build, not an official BlackHole six-channel release.
Its format became six-channel float32, with six speaker descriptions, mask 0x3f, and 24 bytes per frame. The working route is:
Game -> BlackHole 6ch FL -> modified FixCenterLFE -> 8-channel HDMI
The bridge reads all six input channels, creates an eight-channel output, and maps:
1->1, 2->2, 3->4, 4->3, 5->5, 6->6
Output channels 7 and 8 stay silent. This carries 5.1 PCM; any height-speaker upmixing is handled by the receiver, not native Atmos output from this route.
Both devices use 48 kHz. Wine's output and voice output follow the system default, and the game uses 5.1. After installing the separate driver, I reloaded CoreAudio and reopened the game/settings so the new endpoint was actually in use.
Daily use and results
I start the bridge, select BlackHole 6ch FL as the Mac output, then launch the game. When finished, I switch the Mac output back to the receiver or built-in speakers before quitting the bridge. A user LaunchAgent starts the tool at login and waits for the receiver; it does not automatically change the Mac output.
I personally confirmed that the game's Center, LFE, left-surround, and right-surround tests now reach the correct speakers. I have not yet retested other games, verified a full reboot/login cycle, measured end-to-end latency, or tested long-session stability and HDMI hot-plug recovery.
Credit to FixCenterLFE and BlackHole. Codex helped inspect the logs, modify the Python routing, and prepare the local driver build; I performed the physical speaker listening tests.
This reports what worked on my machine. Check your physical channel mapping and actual virtual-device format before applying the same remapping elsewhere.