Proton startup delay when using winepulse.drv

[MacSvensson]

Summary
Since a recent system update, every Proton game experiences an approximately 30-second delay between launching the game executable and the appearance of the game window. Replacing winepulse.drv with winealsa.drv removes the delay completely, suggesting a regression in the PulseAudio/PipeWire backend.

System

• Debian GNU/Linux 13 (Trixie)
• Kernel 6.12.100-1-amd64
• PipeWire 1.4.2
• WirePlumber 0.5.8
• Mesa 25.0.7
• RADV (RX7600)
• Steam Runtime (Pressure Vessel)
• Proton 9.0 / 10.0 / 11.0

Games tested

• Age of Wonders III
• Baldur's Gate 3

Measured startup times

Age of Wonders III
Launcher: ~8–10 s (same with and without workaround)
Play → fullscreen
Without workaround: 34 / 31 / 31 s
With workaround: 1 / 1 / 1 s

Baldur's Gate 3 (--skip-launcher)
Steam Play → first fullscreen window
Without workaround: 46 / 46 / 47 s
With workaround: 18 / 17 / 17 s

Workaround
WINEDLLOVERRIDES="winepulse.drv=b;winealsa.drv=n" %command%

Additional observations

• Reproducible
• Multiple games
• Multiple Proton versions
• Delay occurs before first window
• Audio works normally once started
• ALSA backend removes the ~30 s delay

Expected behaviour
Games should launch without the additional ~30 second delay while using winepulse.drv.

Actual behaviour
Games consistently spend approximately 30 additional seconds during startup when using winepulse.drv.

Question
Is this a known regression in winepulse.drv (or its interaction with recent PipeWire/PulseAudio changes), or is additional debugging information required?

steam-226840.log

[kisak-valve]

Hello @MacSvensson, this reads like ValveSoftware/SteamOS#2504. Can you check if your system is similar?

[MacSvensson]

Thanks! I hadn't found the SteamOS issue during my search, but it does indeed look very similar.

My system currently has no physical capture device available.

During my investigation I tested this hypothesis by creating a dummy capture source in PipeWire:

pactl load-module module-null-source source_name=dummy_mic source_properties=device.description=Dummy-Microphone

The dummy source was created successfully, appeared in PipeWire, and was enumerated correctly by Wine.

However, it did not change the behaviour. The startup delay remained essentially identical. I then unloaded the dummy source again, restarted Steam, and repeated the timing measurements. The results were unchanged.

The only workaround I found that consistently removes the startup delay is:

WINEDLLOVERRIDES="winepulse.drv=d;winealsa.drv=b" WINEALSAOUTPUT=default %command%

Is the SteamOS issue expected to be resolved by the presence of any capture source, or does it specifically require a physical capture device?