In the mean time I did some more testing. Connecting the Linux host directly to the AV receiver via HDMI worked as expected; all surround channels are correctly mapped. This indicates that it is most likely not the NVIDIA driver but Steam itself.

I double checked with another PC using the same Ubuntu MATE 18.04.2 LTS, also with an NVIDIA graphics card, but this time a GTX 1070 (instead of the GTX 1060). Both have the same drivers.
The mismatch in channels happens also on that PC as host when streaming via Steam.

I tried to see if the channel mismatch was related to HDMI; so I enabled the onboard audio again, chose Analog 5.1 Surround as profile. That gave exactly the same result as HDMI with wrong channels mapped.

I can confirm the problem. I have exact the same setup and the same problem described above.

I’m in 19.04 and I get a pretty similar situation.
While testing with a surround video.
FR = RR
FC = RR
FL = RL
RR = RR+FR
RL = RL+RL
Sub = none (but I have one)

When I switch the audio in stereo mode I barely hear my front speaker... which work perfectly on all my other device.
I’m new on Ubuntu, the same pc had W10 and everything was perfect before switching to Ubuntu. I mean surround and stereo worked perfectly.

My htpc is directly plugged in my home theatre. All update are done.
Spec.
I5-2400, gtx 670, 8gb, ssd 30gb.

I just set up a dual boot with Ubuntu 20.04 (plan is to kick Microsoft to the curb asap) and have run across this same issue with remote play streaming on my home network.

Operating System Version:
Ubuntu 20.04.3 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 5.11.0-37-generic
X Server Vendor: The X.Org Foundation
X Server Release: 12011000
X Window Manager: Mutter (Muffin)
Steam Runtime Version: steam-runtime_0.20210906.1
CPU Brand: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
RAM: 15971 Mb
Video Card: Driver: NVIDIA Corporation NVIDIA GeForce GTX 1070/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 470.63.01
Audio device: Realtek ALC892

Steam client application
Built: Sep 17 2021, at 04:30:38
Steam API: v020
Steam package versions: 1631912732

I have tried adjusting the /etc/daemon.conf file with the following edits:

remixing-produce-lfe = yes
remixing-consume-lfe = yes
lfe-crossover-freq = 80
default-sample-rate = 48000
default-sample-channels = 6
default-channel-map = front-left,front-right,rear-left,rear-right,front-center,lfe

My receiver is a Sony STR DH-550, I have tested with both the hardware Steam Link and the Steam Link app on my Raspberry Pi 3B+, with both I get this test result using the Analog Surround 5.1 Output:

FL=FL&FR
FC=FC & RR
FR=RL
RL=FR
RR=RL
LFE=FC with modified daemon.conf, NO sound with unmodified daemon.conf

Even when I select Analog Stereo Output, the FL=FL but the FR=FC.

Using Windows 10 the audio is correct on all channels/speakers, whether using the Steam Streaming Speakers or the Realtek Onboard Audio device.

This is the only issue I've run across that is holding me back from ditching Windows, as I game in my living room recliner via the Steam Link ... but with the audio not working properly, I have to keep Windows for gaming.

Edit: I installed pavucontrol to see if it might help and I noticed that under Recording the listing for Steam shows an odd channel listing when you unlock them ... Front Left, Front Left of Center, Front Center, Front Right, Front Right of Center, Rear Center.

The Output Devices when unlocked show what I would expect ... Front Left, Front Right, Rear Left, Rear Right, Front Center, LFE.
Is it possible that the problem lies within what Steam Streaming recording is set for?

Edit 2: I removed pavucontrol since it didn't seem to be helping me any, then ran the update/upgrade commands even though I did that before installing pavucontrol earlier today and 3 files updated (unfortunately I didn't pay attention to file names).

Now when Gnome is set to analog stereo and the steam link is set to stereo, I at least get proper stereo channels in the stream, but when I select analog 5.1 in Gnome the test results are now FL=FL, FR=FR, RL=FL quieter, RR=FR quieter, FC=FL & FR balanced, and no LFE when steam link is set to stereo, but still all over the place as in my original post when the steam link is set to 5.1.

I've noticed that the issue is with the Steam recording for the streaming. With 5.1 analog set in the gnome sound control and 5.1 set in the steam link, pavucontrol shows both the Input Devices and Output Devices are using the correct channel map, start streaming and then check the Recording tab and Steam is recording and thus sending the wrong channels. This appears to be something in the Steam streaming client that is not properly mirroring the channels used in the Input and Output Devices.

Just updating. Currently on linux mint 20.2 cinnamon desktop, the issue persists when streaming to the link as previously detailed. I did unplug and take my pc to the living room, hooked it up via hdmi from the nvidia card to the receiver and 5.1 audio worked fine. I also purchased an hdmi headless plug that simulates up to 7.1 surround sound in the hope that steam might accept that as being connected to an actual 5.1 speaker setup and record correctly, it did not work either.

Just chiming in to say that I also have this exact same issue in Linux Mint 20.2 cinnamon. In pavucontrol I can see Steam is recording 6 channels from my 5.1 output by Monitoring it, but the channels it's getting are listed as follows:
Front Left, Front Left-of-Center, Front Center, Front Right, Front Right-of-Center, Rear Center
whereas the output that Steam is recording from has its channels listed thusly:
Front Left, Front Right, Rear Left, Rear Right, Front Center, LFE

Can confirm @entropicdrifter . Had this issue today and tried figuring out what's going on.

My setup at the PC is a USB DAC with stereo sound, it does not support surround sound. Before I want to stream with steam, I need to select audio HDMI surround before opening steam and opening steam link. This way steam remote play is opened with the monitoring channel on correct surround device. But still, with incorrect mapping it isn't any useful.

I'm using a AMD RX5500XT, so it doenst seems to be related to NVIDIA only.

Is it an idea to create two virtuale devices (just like windows) where steam remote play automatically streams the audio from? This way anyone with a stereo setup like me can enjoy surround without doing some clicks first in pavucontrol.

Since this has been an open issue for the past 3+ years, it's clear that Valve is unable to fix this, unwilling to fix it, or just considers surround sound for steam streaming on linux to be too small a user percentage to waste time with.

Therefore, I've boxed the steam link and the Pi is being used as a stand alone mini pc. My gaming rig is now in my living room component cabinet, had to cut a panel out of the back for airflow and cabling, 4 peel and stick feet on the side of the case so I could slide it in neatly (also takes the torque off the graphics card and cpu cooler). With it directly hooked up to the receiver the surround sound is perfect, zero input lag and the picture is very noticeably better. If you can, I recommend moving your gaming rig into the room with the receiver and big screen.

@Xenophobe-01
For what it's worth I use Sunshine/Moonlight to stream from my main PC to my big TV and it handles surround sound just fine

Just chiming in that I'm experiencing this same thing. I'm assuming Xenophone-01 is right in their assumption that a) steam in-home streaming users b) with a Linux host c) using surround sound is such a ridiculously insignificant subset of users that this issue is realistically not going to get resolved.

But in any case, this is my setup:

• Denon AVR-891 with 7.1 surround
• Windows 10 client
  • NVIDIA GT 635M GPU
  • Steam Link app version 1.2.0.241*
• OpenSUSE Tumbleweed (updated yesterday, 2023-05-29)
  • Steam version 1685072487
• Pipewire as audio engine (libpipewire 0.3.71)

The Windows 10 PC is connected via HDMI and, as tested through Windows sound settings, the surround channels are mapped and connected correctly. I did get 2 sets of results while testing surround through Steam Link that are interesting, though.

When both Windows and the Steam Link app are configured for 5.1 output, the channel mapping is as such:
FL is FL
FR is LFE
RL is RR
RR is also RR?
FC is FC
LFE is... FC plus LFE but FC is quieter?

When both Windows and the Steam Link app are configured for 7.1 output, the channel mapping is as such:
FL is FL
FLC is FR
FC is FC
FR is LFE
FRC is SL
RC is SR
AUX0 is nothing
AUX1 is nothing

I have not tried Windows configured with 7.1 and Steam Link configured with 5.1, that might be interesting...

To clarify these results, the channel name on the left is the software name and the channel on the right is the observed actual output. The channel names on the left were the ones observed in Helvum for channel mapping, but I had the same thing as mentioned by a few others in here that the channel names (as observed in Pavucontrol) for the Steam recording stream included left-of-center and such -- they were not the standard 5.1 and 7.1 digital surround channel mappings.

* Steam Remote Play/in-home streaming isn't working at all for me from linux to a Steam client on Linux or WIndows, but it does work to the Steam Link app. That's a separate issue and I didn't spend much time troubleshooting it anyway

This is not just Nvidia or Analog/HDMI profile issue.
Surround sound via Steam Link App simply does not work. It only maps to L/R and SW channels.
I tested it with the Analog profile of my on-board soundcard as well as the HDMI profile of my GPU with the Fraunhofer AAC LFE and SBR Test - H.264 Video in mpv on the AppleTV Steam Link app.

Edit: it seems EasyEffects was altering the sinks on pipewire, however they remain wrong. After removing the audio software, now my Steam host transmits to my Apple TV Steam Link audio on front left, LFE and right surround channels.

I grabbed Ghost of Tsushima in the spring sale, and there was no way I was playing it in stereo, so I came up with a workaround. Thanks to @entropicdrifter for the detail-oriented testing.

Using pipewire-pulse, make a 5.1 virtual sink, and a remapped source using the configuration below. I placed it in ~/.config/pipewire/pipewire-pulse.conf.d/50-steam-remap.conf

pulse.cmd = [
	{ cmd = "load-module" args = "module-null-sink sink_name=steam_workaround channel_map=front-left,front-right,front-center,lfe,side-left,side-right" }
	{ cmd = "load-module" args = "module-remap-source master=steam_workaround.monitor master_channel_map=front-left,front-right,front-center,lfe,side-left,side-right channel_map=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center remix=no" }
]

Incidentally the null sink will also help if you're like me and you don't always have a surround sink available to your streaming host.

Then using pavucontrol -> Output Devices, set steam_workaround as the default sink. Once the stream is active, set pavucontrol -> Recording -> Steam's dropdown to Remapped steam_workaround source.

Edit: Remap's master should be steam_workaround.monitor not steam_workaround

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/6150#issuecomment-2733518573

This didn't do anything on my system. Pavucontrol does not show any new sinks even after restarting pipewire and wireplumber.

Pavucontrol does not show any new sinks even after restarting pipewire and wireplumber.

Do you have pipewire-pulse?
If you copied my path, check this to ensure the config will be found for you.

Edit: failing that what do journalctl -xe | grep pipewire and systemctl --user status pipewire-pulse look like?

Pavucontrol does not show any new sinks even after restarting pipewire and wireplumber.

Do you have pipewire-pulse? If you copied my path, check this to ensure the config will be found for you.

Edit: failing that what do journalctl -xe | grep pipewire and systemctl --user status pipewire-pulse look like?

Yes:
zypper se pipewire-pulse
Loading repository data...
Reading installed packages...

S | Name | Summary | Type
---+---------------------+------------------------------------+--------
i | pipewire-pulseaudio | PipeWire PulseAudio implementation | package

I created the conf file in ~/.config/pipewire.conf.d/50-steam-remap.conf

Apparently in openSUSE pipewire configuration files are read from
~/.config/pipewire/pipewire-pulse.conf.d

While pavucontrol now shows both new sinks, when selected all sound is muted from the host computer and the guest computer shows no change, no decode message sent to the AVR; when selecting the Recording sink in pavucontrol, the option "Monitor of steam_workaround Audio/Sink sink" is the default and you wrote to select Remapped steam_workaround source which immediately changes back to "Monitor of steam_workaround Audio/Sink sink".

Second test run with FFXIV plays sound but only in front left and rear right. Recording panel still won't take Remapped steam_workaround sink and host computer is completely muted.

Recording panel still won't take Remapped steam_workaround sink

I've seen this behavior when pavucontrol -> Output Devices default is set to Remap. Also check the updated code block from my first post.

host computer is completely muted

This is expected because steam_workaround is a null-sink. If that is a deal-breaker, you'll need a different configuration.

Ok, it works now as described.
It's not a deal breaker, I can just change the device when playing at the host. It's such a manual setup right now anyway.
Interestingly, the audio crackling I fixed in the past with PULSE_LATENCY_MSEC=60 is gone when using these sinks. The launch argument was removed before trying your fix.

Hey @jeffgriffin Do you happen to have No Man's Sky? It's the only game in my library that does not work at all using your workaround. When I use it, the game stream has no sound but everything plays on the host machine.

I do. I haven't tried to stream it (or anything very recently). I see activity in PulseAudio Volume Meter on all channels for all outputs on my system though, including steam_workaround.

Just wanted to add that I have a similar issue with Steam Remote Play and my Fedora host, streaming to my Steam Deck. The Steam Deck is connected to a Denon S760H receiver via an HDMI 2.1 cable and UGREEN dock. 5.1 is enabled in the Steam Remote Play settings for both the host and the client. The Denon reports that the Steam Deck is receiving multichannel audio from the Steam Deck, and it seems to work fine when running games locally on the Steam instead of streaming. Multichannel audio also works fine when streaming from Sunshine (on the host) to Moonlight (on the steam deck).

The difference is that I can't get 5.1 surround to work at all. The workaround posted by jeffgriffin above doesn't appear to work for me. When I follow these directions,

Once the stream is active, set pavucontrol -> Recording -> Steam's dropdown to Remapped steam_workaround source

it almost completely cuts out the front right channel (perhaps pushing rear channels?), as observed in pavumeter. Before that step, it only outputs the front left and front right channel, despite having changed my default output to the steam_workaround sink.

Host Details:

Steam Beta Branch: Stable Client
Steam Version: 1759461205
Steam Client Build Date: Thu, Oct 2 9:27 PM UTC -08:00
Steam Web Build Date: Thu, Oct 2 1:12 PM UTC -08:00
Steam API Version: SteamClient023

Hardware Information:
Hardware Model: ASRock B850 LiveMixer WiFi
Memory: 32.0 GiB
Processor: AMD Ryzen™ 7 9800X3D × 16
Graphics: AMD Radeon™ RX 9070 XT
Graphics 1: AMD Ryzen™ 7 9800X3D
Disk Capacity: 5.5 TB

Software Information:
Firmware Version: 3.20
OS Name: Fedora Linux 43 (Workstation Edition)
OS Type: 64-bit
GNOME Version: 49
Windowing System: Wayland
Kernel Version: Linux 6.17.7-300.fc43.x86_64

I do. I haven't tried to stream it (or anything very recently). I see activity in PulseAudio Volume Meter on all channels for all outputs on my system though, including steam_workaround.

I figured it out. Apparently, my USB DAC was throwing a wrench into the solution, as soon as I disconnected it, everything worked again.

Hey @jeffgriffin something really broke your workaround and now pavucontrol refuses to change to remapped.

PipeWire 1.6.1 / WirePlumber 0.5.13 breaks workaround (stream.capture.sink)
The workaround posted by @jeffgriffin with assistance from @entropicdrifter no longer works with PipeWire 1.6.1 and WirePlumber 0.5.13 on openSUSE Tumbleweed.

Root cause: Steam now launches its capture stream with stream.capture.sink = true, which causes it to capture the sink monitor directly, bypassing the remapped source entirely. A WirePlumber patch (0003-default-nodes-Never-consider-Audio_Sink-nodes-as-best-for.patch) introduced on March 2, 2026 appears to have triggered this behavior change.

New workaround using module-remap-sink:
Instead of remapping the source, remap the sink itself so Steam captures the monitor with channels already in the correct order. Place this in ~/.config/pipewire/pipewire-pulse.conf.d/50-steam-remap.conf:

pulse.cmd = [
  { cmd = "load-module" args = "module-null-sink sink_name=steam_input channel_map=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center" }
  { cmd = "load-module" args = "module-remap-sink sink_name=steam_workaround master=steam_input master_channel_map=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center channel_map=front-left,front-right,front-center,lfe,side-left,side-right remix=no" }
]

Set steam_input as the default output device in pavucontrol. No manual intervention in the Recording tab required.
Known issue as reported by @ExponentialEntropy : Front Right channel is still silent.
Extensive testing shows Steam Link silences any channel placed in position 1 of the sink monitor regardless of channel name. This appears to be an existing bug in Steam Remote Play unrelated to the PipeWire update.

As an FYI, this was investigated and written with the help of ClaudeAI. I am ver very far from being not just a software engineer, but also one with audio experience or a sound engineer.

Also, @kisak-valve can you change the title? This is not limited to Nvidia hardware or HDMI. My system has nothing connected via HDMI, in fact it has nothing connected to the other outputs on my mainboard audio, just line out.

I was just testing this. The original workaround is still functional for me. It's probably fine to use a module-remap-sink though, just don't apply it to any other sink (i.e. the server's multichannel hardware sound output).

If you're using pavucontrol, make sure the Recording tab is showing All Streams. If it's only showing Virtual Streams, you won't see applications like Steam.

At any rate, these workarounds are primarily to show exactly what/where the problem is, in order to help fix it.
I should think this bug would be relatively higher priority now, seeing as it will affect streaming from Valve's new hardware? @slouken

At any rate, these workarounds are primarily to show exactly what/where the problem is, in order to help fix it.
I should think this bug would be relatively higher priority now, seeing as it will affect streaming from Valve's new hardware? @slouken

It's a 7 year bug. I have a hunch fixing this is not on their radar. IIRC SteamOS on the Steam Deck maps multichannel audio correctly when streaming.

The channel mapping bug is host-side. If you dock a Steamdeck so you can run HDMI to a multichannel receiver, it will fail the same way anything does. I know this, because I've done it. I assume this hasn't been a high priority because Valve has decided most folks are not streaming multi-channel audio from Linux hosts very often. If Valve releases the steam machine this year without fixing this bug streaming multi-channel audio will fail.

I was just testing this. The original workaround is still functional for me. It's probably fine to use a module-remap-sink though, just don't apply it to any other sink (i.e. the server's multichannel hardware sound output).

Are you also running Pipewire 1.6.1 and wireplumber 0.5.13?

If you're using pavucontrol, make sure the Recording tab is showing All Streams. If it's only showing Virtual Streams, you won't see applications like Steam.

It shows All Streams and Steam is in the list, however, when I select the remapped entry from the dropdown menu, it goes back to monitor and the sound never moves, it's stuck in Front Left, Surround Right and LFE. I have noticed that with the incorrect mapping, my apartment really really rumbles, probably other channels are converging on LFE?

Are you also running Pipewire 1.6.1 and wireplumber 0.5.13?

Yes

It shows All Streams and Steam is in the list, however, when I select the remapped entry from the dropdown menu, it goes back to monitor and the sound never moves...

I am not experiencing this. If using module-remap-sink is working for your needs, do it.

it's stuck in Front Left, Surround Right and LFE. I have noticed that with the incorrect mapping, my apartment really really rumbles, probably other channels are converging on LFE?

The details of the mapping failure mode have been well-defined elsewhere in the thread.

Hi there!

Super happy I found this topic!

Currently I stream from Ubuntu 26.04 (before I was on CachyOS) to an Apple TV 4K attached to a 5.1 AVR in my living room. And every time I select 5.1 in the app on the ATV 4K, only the front left speaker plays. With Stereo I at least get, well, Stereo.

On my computer I am using a pair of B&W MM-1 Stereo USB speakers wich are selected in Pavucontrol's recording tab as the source for the Steam recording.

I have not tried the re-mapping workaround somewhere above, but will it really help? Or will I have to somehow create a virtual surround capable sink which then is selected as the source for Steam recoding in Pavucontrol?

Sorry, I am not a total noob, but this entire Linux sound setup topic is still pretty new to me :-).

Thank you very much!!!

I hit this on an Xorg/KDE Arch host streaming to a Steam Link on a Shield TV (2015), and filed #13610 before finding this thread — apologies for the duplicate. Cross-linking, since I think it pins down the mechanism this thread has been circling, and it matches @SpoOokY1983's "only the front left speaker plays, with Stereo I at least get Stereo" exactly.

The host creates its capture sink with no channel positions, then records it with the AIFF map.

streaming_log.txt:

PulseAudio: Recording on device steam-streaming-playback.monitor
PulseAudio: Using sample spec 's16le 6ch 48000Hz', channel map
  'front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center'

pw-dump for that sink shows audio.channels = 6 with no audio.position key at all, so pactl reports it as aux0..aux5. That map is PulseAudio's default 6-channel map, PA_CHANNEL_MAP_AIFF (RFC3551) — which is where the front-left-of-center / front-right-of-center names in this thread and in #4502 come from. In it, front-right is at index 3, and the client decodes the wire as standard 5.1 (FL, FR, FC, LFE, RL, RR), so index 3 is LFE.

That explains @lavadrop's "my apartment really really rumbles": the right channel is being sent to the subwoofer.

Reproducible without Steam. Unpositioned 6ch null sink, captured with the AIFF map, fed a stereo tone (L=300 Hz, R=900 Hz); per-channel FFT of the capture:

wire slot 0 (client plays as FL ) <- LEFT
wire slot 1 (client plays as FR ) <- silent
wire slot 2 (client plays as FC ) <- silent
wire slot 3 (client plays as LFE) <- RIGHT
wire slot 4 (client plays as RL ) <- silent
wire slot 5 (client plays as RR ) <- silent

Changing only the capture map to surround-51, everything else identical, fixes it:

client FL  <- LEFT
client FR  <- RIGHT

Capturing the same unpositioned sink with a matching aux0..aux5 map also routes correctly (left→slot 0, right→slot 1), which isolates the fault to the AIFF map request rather than to playback into an unpositioned sink.

Note on the AIFF map itself: it contains neither LFE nor discrete rear-left/rear-right. So 5.1 content cannot survive it intact even in principle, regardless of host configuration — which may be why remapping workarounds keep coming out partial.

Config-level overrides that do not work (documented so they can be ruled out): forcing audio.position on the sink via PipeWire node.rules (the rule applies, but module-null-sink's own args override it, position stays UNK); forcing audio.position on the capture stream via stream.rules (rule applies and is visible in pw-dump as [ FL, FR, FC, LFE, RL, RR ], but routing is unchanged — the format negotiated from the client's libpulse channel map wins); channelmix.disable (disables the mixing matrix, not the channel remap); a correctly positioned 5.1 default sink (Steam logs it, then creates and records its own sink anyway); and STEAM_RUNTIME=0.

Suggested fix: pass an explicit channel_map (e.g. surround-51) when creating the record stream instead of relying on the PulseAudio default, and/or set audio.position on steam-streaming-playback at creation so the sink and the capture stream agree.

Full write-up, measurements and repro script: https://gist.github.com/moonwhaler/5e3b1b6d8378243771a3223182229959

Environment: Arch Linux, kernel 7.2.4, Steam build 1788652215 (stable), PipeWire 1.6.8 / pipewire-pulse 1.6.8 / WirePlumber 0.5.17, libpulse 17.0+r98, RTX 4090 driver 615.71.09, Xorg + KDE Plasma. Client: Steam Link 1.3.32.315, Shield TV (2015), Android 11, set to 5.1. Sunshine/Moonlight streams correct 5.1 from the same host.

@lavadrop — going to test your module-remap-sink version next and will report per-channel measurements, specifically on whether the "position 1 is always silenced" behaviour reproduces here.

Correction and refinement to my previous comment, plus confirmation that @lavadrop's module-remap-sink workaround works here.

I had a measurement artifact: paplay defaults a 6-channel file to the AIFF map, which happens to match Steam's request and cancels the bug out. Forcing --channel-map=surround-51 to represent what a real application declares gives a much cleaner picture than "the front channels are permuted".

The exact failure is that front-right and LFE are swapped. Applications declare surround-51; the capture stream requests AIFF, which has no LFE and no discrete rear-left/rear-right. PipeWire matches what it can by label, then fills the remaining target slots in order:

The client reads indices 1 and 3 as FR and LFE, so:

5.1 source:                        stereo source:
  client FL   <- game FL             client FL   <- LEFT
  client FR   <- game LFE   wrong    client FR   <- silent     (front-right dead)
  client FC   <- game FC             client FC   <- silent
  client LFE  <- game FR    wrong    client LFE  <- RIGHT      (right in the sub)
  client RL   <- game RL             client RL   <- silent
  client RR   <- game RR             client RR   <- silent

This explains both reported symptoms with one mechanism. Stereo sources match only FL→0 and FR→3, so the right channel goes to the subwoofer and the front-right speaker is silent — that is @SpoOokY1983's "only the front left speaker plays". For 5.1 sources the right speaker emits LFE rumble while the sub gets right-channel content, which is easy to mistake for working surround. On my host, Control sounded plausibly surround while Everspace 2 and Big Picture (both stereo) collapsed to front-left.

It also accounts for @lavadrop's "other channels are converging on LFE" and the "position 1 is silenced" observation: index 1 is front-left-of-center, which no surround-51 source ever matches by label, so it only ever receives an unmatched channel.

@lavadrop's module-remap-sink workaround is correct and works. I adapted it slightly for PipeWire 1.6.8 — using rear-left,rear-right rather than side-left,side-right in the application-facing map, and setting steam_workaround (not steam_input) as the default sink, since applications need to target the remap sink for the remap to apply:

pulse.cmd = [
  { cmd = "load-module" args = "module-null-sink sink_name=steam_input channel_map=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center" }
  { cmd = "load-module" args = "module-remap-sink sink_name=steam_workaround master=steam_input master_channel_map=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center channel_map=front-left,front-right,front-center,lfe,rear-left,rear-right remix=no" }
]

Then systemctl --user restart pipewire-pulse and pactl set-default-sink steam_workaround.

Measured per-channel through that chain, both stereo and 5.1 sources come out correct on all six channels, including front-right — so I do not reproduce the "front right is still silent" limitation, at least in the local capture chain. @ExponentialEntropy, the steam_workaround-as-default detail may be what differed for you.

Note for anyone reproducing this: verify your test file's channel order before trusting results. ffmpeg's join filter reordered channels on me, and paplay without an explicit --channel-map masks the bug entirely. Updated write-up with the full method: https://gist.github.com/moonwhaler/5e3b1b6d8378243771a3223182229959

The underlying fix is still one line on Valve's side: pass an explicit channel_map (e.g. surround-51) when creating the record stream, or set audio.position on steam-streaming-playback at creation, instead of relying on PulseAudio's default 6-channel map (PA_CHANNEL_MAP_AIFF).

The published workaround silently bypasses itself on PipeWire, and there is a second step missing. Both are fixable — I now have correct 5.1 on stereo and native-5.1 titles.

Two findings that I think explain @ExponentialEntropy's "front right is still silent" and @lavadrop's "pavucontrol refuses to change to remapped".

1. PipeWire ignores module-remap-sink's master=

It binds the remap sink's output to whatever is currently the default sink, not to the sink named in master=. The argument is accepted and visible in pactl list modules, so it looks correct — but the filter is wired somewhere else entirely and steam_input never receives anything. On my host the remap output had attached itself to my motherboard analogue output.

Check whether this is happening to you:

pactl list sink-inputs | grep -E 'Sink Input #|Sink:|node\.name'
pactl list sinks short | grep steam_input

The stream named output.steam_workaround must show a Sink: index equal to steam_input's index. If it doesn't, the whole remap is being bypassed and you are still hearing the raw bug.

Fix — load order. Make the AIFF sink the default before loading the remap sink, so it binds to the right thing, then hand the default over to the application-facing sink:

AIFF=front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center
S51=front-left,front-right,front-center,lfe,rear-left,rear-right

# 1. capture sink: its map IS the map Steam asks for, making Steam's capture an identity conversion
pactl load-module module-null-sink sink_name=steam_input \
  sink_properties=device.description=Steam-Remote-Play-Capture \
  channels=6 channel_map="$AIFF"

# 2. must be default BEFORE the remap loads, or master= is ignored
pactl set-default-sink steam_input

# 3. application-facing sink: normal 5.1 names out, positional copy in
pactl load-module module-remap-sink sink_name=steam_workaround \
  sink_properties=device.description=Steam-Remote-Play-5.1 \
  master=steam_input master_channel_map="$AIFF" channel_map="$S51" remix=no

# 4. applications and games follow the default sink
pactl set-default-sink steam_workaround

If step 3 still lands wrong, move it explicitly:
pactl move-sink-input <id-of-output.steam_workaround> steam_input

I also used rear-left,rear-right rather than side-left,side-right in the application-facing map, since that is what surround-51 sources actually declare.

2. Steam captures the monitor of its selected output device

Not its internal steam-streaming-playback sink, and not necessarily the default sink — whichever output device is chosen in Steam's own audio settings. So selecting the 5.1 device (steam_workaround) in Steam re-creates the original bug, because that sink carries real 5.1 labels and Steam requests AIFF against it.

Steam must capture steam_input.monitor — the AIFF-mapped sink — so the conversion is an identity:

pactl list source-outputs | grep -E 'Source Output #|Source:|application\.name'
pactl move-source-output <steam-id> steam_input.monitor

Equivalently, pick Steam-Remote-Play-Capture in Steam's audio settings, not the 5.1 one. This is counter-intuitive: the device that looks like the surround one is the wrong choice.

Steam re-targets this stream when streaming starts and when its audio device changes, so a one-shot move isn't enough — I run a 2-second poll that re-pins it for the life of the session.

Result

With both fixes, measured per-channel on the wire Steam sees (one distinct tone per channel):

5.1 source:                 stereo source:
  client FL   <- FL           client FL   <- LEFT
  client FR   <- FR           client FR   <- RIGHT
  client FC   <- FC           client FC   <- silent
  client LFE  <- LFE          client LFE  <- silent
  client RL   <- RL           client RL   <- silent
  client RR   <- RR           client RR   <- silent

Exact identity on 5.1, correct left/right on stereo. Confirmed by ear over an actual stream to a Shield TV on a 5.1 receiver: Steam Big Picture and Everspace 2 (both stereo) now play from both front speakers instead of front-left only, and Pragmata (native 5.1) is correct — front-right carries real content and the subwoofer only carries LFE.

I do not reproduce the "any channel in position 1 is silenced" behaviour. @lavadrop, I believe that was the master= bypass rather than a separate Steam bug: with the remap bypassed, the sink Steam captures has 5.1 labels, so front-left-of-center at index 1 is a label no surround-51 source ever matches, and it is therefore always empty. Once the chain is wired correctly, index 1 carries front-right normally.

Worth stressing for anyone testing by ear: with the raw bug, front-right and LFE are swapped on native-5.1 titles, which sounds plausibly like working surround. I was fooled by exactly that before measuring. The giveaway is that the subwoofer carries full-range content — dialogue and effects, not just rumble.

Caveat: steam_input is a null sink, so the host's own speakers are silent while it is the default output.

I've wrapped this into my Steam launch script so it is created on start and fully reverted on exit (unload both modules, restore the previous default sink). Details and the measurement method: https://gist.github.com/moonwhaler/5e3b1b6d8378243771a3223182229959

None of this reduces the need for the one-line fix on Valve's side — pass an explicit channel_map (e.g. surround-51) when creating the record stream, or set audio.position on steam-streaming-playback at creation, instead of relying on PulseAudio's default 6-channel map (PA_CHANNEL_MAP_AIFF).