Apollo/Moonlight 7.1 audio consistently downmixes to 5.1 — anyone solved this?
Hoping someone has cracked this. I've been chasing 7.1 audio over Moonlight for hours and keep hitting the same wall.
Setup:
- Host (gaming PC): Windows 11, RTX 5090, headless (monitor is an AW3225QF that's usually off). Running Apollo latest.
- Client (living room mini PC): Windows 11, minisforum mini PC, connected via HDMI to LG C5 TV, then eARC to Samsung HW-Q990D soundbar (11.1.4).
- Network: wired, no bandwidth issues.
What works:
- Local playback on the mini PC: TrueHD Atmos via MPC-HC bitstreams cleanly through the TV's eARC to the soundbar. Soundbar display shows
DOLBY ATMOS. Full 11.1.4 rendering, heights working as intended. The audio chain itself is verified solid. - Stereo content via Moonlight: works fine.
The problem:
Anything 7.1 over Moonlight downmixes to 5.1 by the time it reaches the soundbar, and the rear satellites end up reproducing what should be side channels (I imagine that since 5.1 has no rear L/R, the soundbar routes side content to the rears).
What I've configured:
- Host PC: Windows audio set to 7.1 Surround on Steam Streaming Speakers. Confirmed in Configure dialog (though I notice in Windows' built-in test, the side L/R channels also don't produce tones — only 6 of 8 fire, which matches what others reported in moonlight-android issue: https://github.com/moonlight-stream/moonlight-android/issues/1295).
- Apollo: Audio Sink set explicitly to Steam Streaming Speakers. Virtual Sink also set to Steam Streaming Speakers. Tried leaving Audio Sink blank, and VB hi-fi cable — same result.
- Moonlight client: Audio Configuration set to 7.1 Surround explicitly.
- Tested with known 7.1 sources, which would otherwise work when directly playing from the mini pc.
Questions:
- Has anyone actually achieved true 7.1 (8 channels) over Sunshine/Moonlight to a soundbar?
- If you got 7.1 working, what was the specific audio sink config that did it?
- Is this a Sunshine/Apollo capture-stage limitation, an Opus encoding limitation, or a Steam Streaming Speakers driver limitation? (The GitHub threads I found suggest it might be capture-stage and not really fixable by changing the audio sink.)
I'm aware that Atmos object-based audio can't survive Opus encoding by design — I've accepted that. But getting clean 8-channel PCM seems like it should be possible
Any insight appreciated. If anyone has working sunshine.conf snippets or specific driver configs that delivered true 7.1, please share.
Solved:
- Short version: On the client end, switching the audio configure from "Dolby Atmos Home Theatre" to plain 7.1 solves the issue.
- Long version: Apparently the windows audio renderer "Dolby Atmos Home Theatre" has been messing with the true 7.1 audio from upstream. It wraps the 7.1 PCM into whatever format before sending to the soundbar and lost 2 side channels in such process (it is highly probable that the "Dolby Atmos Home Theatre" is actually a 5.1 bed + some objects). I was under the wrong mental model that the aforementioned configure should be selected for Apps other than Moonlight to receive Dolby signal. However as one of the reply mentioned, many media playback apps such as Plex and MPC-HC use exclusive audio that totally bypass the windows audio endpoint. So, it cost nothing to set the endpoint just plainly "7.1" since most games/apps that would actually use Dolby Atmos will likely to have their exclusive audio endpoint.
Trivia:
The HDMI cable routing matters less than I thought. My lg c5 has an option to "pass through" the audio as bitstream and the q990d can receive/render it flawlessly. Besides, for some video content like competitive gaming, routing hdmi directly to the tv also bypasses the 4k hdr 120 hz bottleneck on the soundbar's end (I haven't verified this statement yet) and allows you to push the full potential of whatever display device you are using.