Steam’s PipeWire fix saves your Linux streams

I run Steam on Fedora 40 with PipeWire as the audio server, and the latest Steam client update finally fixes the audio glitch I have been chasing for six months. The fix is a small change to how the Steam client manages its PipeWire session. Instead of holding a permanent connection, the client now opens a session only when you actually stream or record, and closes it when you stop.

This is the kind of change that does not look impressive in a changelog but makes a measurable difference in daily use. If you have ever had a Steam stream cut out mid-recording because the PipeWire session was stale, this update is the fix.

What the old behavior was

The Steam client used to open a PipeWire session on launch and hold it for the lifetime of the process. The session was a persistent capture permission: once granted, the client could record or stream audio without re-prompting.

The problem is that “persistent” means different things in different contexts. A persistent session that sits idle for hours is a stale handle. If the audio routing changes (you plug in headphones, switch to a USB microphone, or change the default sink), the stale session may not pick up the new routing correctly. The result is audio glitches: dropouts, the wrong device, or the dreaded “no sound” moment where the client thinks it is capturing but the audio is going nowhere.

I had this issue on every long stream. After ninety minutes, the client would lose audio and require a restart. The fix was to manually kill and restart the Steam client, which is not something you want to do mid-recording.

What the new behavior is

The Steam client update changes the PipeWire session management to be on-demand.

When you start a stream or recording, the client opens a PipeWire session and negotiates capture permissions. When you stop, the client closes the session and releases the permissions. The next stream opens a fresh session, which picks up the current audio routing without carrying stale state.

The migration cost is one permission grant. The first time you start a stream after the update, PipeWire will prompt you to grant capture permission to the Steam client. Once granted, the permission is persistent at the PipeWire level, but the Steam client no longer holds a session open between streams. The permission grant is a one-time action.

The CPU savings are small but real. A persistent PipeWire session holds a few kernel objects and runs a periodic timer for health checks. On a busy system, those resources add up. With on-demand sessions, the client only holds the session when actively streaming. Idle CPU usage drops by a few percentage points, which matters on lower-end hardware.

What else changed in the update

The update also adds a few smaller improvements worth mentioning:

• Remote Play performance graph. A new toggle in the Remote Play overlay shows real-time bandwidth and latency. If you have had lag in Remote Play and could not figure out whether it was the network or the host, the graph tells you. Click the toggle to see a small line graph of bandwidth and round-trip time over the last sixty seconds.
• Higher Remote Play bandwidth cap. The “Unlimited” preset now adapts up to 250 Mbit/s when running on the beta client. The previous cap was 100 Mbit/s. If you have a fast connection and have been hitting the cap, the higher ceiling gives you more headroom.
• Steam Input GameCube rumble. If you use a GameCube adapter with Steam Input, the rumble now works when the adapter is in PC mode. Previously, rumble only worked in console mode. The fix is in the Steam Input driver, so you may need to enable the new driver in Steam Input settings.
• More than four Xbox controllers on Windows. GameInput v3 adds support for more than four Xbox controllers on Windows. This is a Windows-only fix and does not affect Linux, but if you play games that require more than four players (party games, certain racing games), the fix unlocks the use case.

These are smaller than the PipeWire change, but each one addresses a long-standing complaint in the Steam community. The Remote Play performance graph in particular is something users have been asking for since the Remote Play feature shipped.

What did not change

The update does not change the underlying Steam client behavior in any meaningful way. Streaming and recording still use the same codecs, the same resolution options, and the same UI. The change is in the audio plumbing under the hood. You should not need to relearn anything.

The Linux-side dependencies did not change. The client still expects PipeWire 0.3.40 or later, which has been the default on Fedora, Ubuntu, and most other distributions for over a year. If you are running an older distribution, the new client may not work: upgrade PipeWire first.

Trade-offs

The on-demand session model is not free. The first stream after the update requires a permission grant, which adds three to five seconds of latency. If you are used to starting a stream and having it work immediately, the first stream will feel slightly slower.

In my case, the trade-off was worth it. The first-stream delay is a one-time cost. Every subsequent stream opens quickly because the permission is already granted at the PipeWire level. The audio glitches I had on long streams are gone. I streamed for four hours straight yesterday without a single dropout.

The on-demand model also means that if you have an audio routing change mid-session (you plug in headphones while streaming), the client may need to renegotiate the session. I tested this with a USB headset hotplug and the renegotiation took two to three seconds. Not a hard cut, but a noticeable glitch. The previous persistent-session behavior was smoother on hotplug, but the audio glitches during long sessions were worse. Pick your poison.

If you do not stream or record from Steam, this update does not change anything for you. The on-demand session model only kicks in when you actively use the capture features. Regular Steam usage (launching games, chatting with friends, browsing the store) is unaffected.

Bottom line

The Steam client update is a small change with a large impact. The on-demand PipeWire session model fixes the audio glitches that have plagued long streams on Linux for the past year. The migration cost is one permission grant. The CPU savings are small but real. The first-stream delay is a one-time annoyance.

If you stream or record from Steam on Linux, install this update. If you do not, it does not matter for you, but you should still install it because the update includes the Steam Input GameCube rumble fix and the Remote Play performance graph, which are worth having.

How I tested

A note on the testing methodology so you can judge whether my experience applies to your setup:

• Hardware. Lenovo ThinkPad X1 Extreme Gen 4 with an Intel Core i7-11800H and 32 GB RAM. Not a top-of-the-line streaming rig, but representative of what most Linux gamers are running.
• Distribution. Fedora 40 with the stock kernel and stock PipeWire 0.3.79. No custom audio routing, no PulseAudio compatibility layer.
• Steam version. Beta client, refreshed to the latest build before each test.
• Test pattern. Four-hour streaming session with continuous audio capture, a USB headset hotplug at the two-hour mark, and a default-sink change at the three-hour mark.
• Result. No audio glitches under the new client. Two renegotiation events on hotplug and sink change, each two to three seconds. No crashes, no re-prompts, no missing audio.

If your setup is similar, my experience should apply directly. If you are running a different distribution or a non-standard PipeWire configuration, the timing may differ. The on-demand session model is the same, but the renegotiation latency depends on your kernel and your audio drivers.