Steam Deck LCD internal speakers crackle while a Proton game runs, because its WASAPI stream drags the speaker sink to quantum 256

Aperta
  • Qualcosa non va?
#3,017 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux
Ambito
audio-video-rtc, game-dev

Direzione di ricerca

Reproduce on a Steam Deck LCD with pw-top, checking whether the speaker sink drops to quantum 256 while a WASAPI shared-mode game runs under Proton. Inspect winepulse and pulse_probe_settings, then test PULSE_LATENCY_MSEC=60 and a native Linux 256-quantum stream. Done means identifying whether Proton's selected period or the Deck speaker path causes the crackle, with a targeted fix and a confirmed sink quantum of 512 during the Proton test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Your system information
  • Steam client version: 1792618285 (steamdeck_stable)
  • SteamOS version: 3.9.5 (build 20261023.100), kernel 7.2.7-valve2, Steam Deck LCD
  • Opted into Steam client beta?: No
  • Opted into SteamOS beta?: No (branch: rel)
  • Have you checked for updates in Settings > System?: Yes
Please describe your issue in as much detail as possible:

What happens: while a Windows game runs under Proton 11.0-2e, the Deck's internal speakers click and crackle at random, on music and sound effects alike, for as long as the game is running. Docked to a TV over HDMI it is clean, and the same game is clean on macOS. The game is ours (Antsy, unreleased, SDL 3.4.14, WASAPI shared mode, 48 kHz float stereo, run as a non-Steam shortcut).

What we measured (PipeWire 1.6.8, clock.quantum 512, clock.min-quantum 256):

  • The game's stream opens with a 256-frame period, and pw-top shows the speaker sink (alsa_output.pci-0000_04_00.5-platform-acp5x_mach.0.HiFi__Speaker__sink) dropping from 512 to 256 while it runs.
  • The mix going to the speaker is clean: a recording of the sink monitor over 60 to 130 s runs had no dropouts or discontinuities and matches the source audio.
  • The sink's ERR count didn't move and its W/Q stayed at or under 0.02. The kernel log is clean.
  • With PULSE_LATENCY_MSEC=60 %command% the sink stays at 512 and the crackle is gone.
  • So the crackle seems to come from the speaker path running at quantum 256, not from the audio data.

Why the game runs at 256: Proton's winepulse (pulse_probe_settings) sets the device default period to the server's smallest minreq, which is 256 frames on the Deck. IAudioClient::Initialize always opens shared streams at that default, although Windows shares at 10 ms and GetDevicePeriod reports 10 ms. GetSharedModeEnginePeriod reports 256 as the maximum, so an app that honours the reported range, as SDL does, can't ask for more.

Expected: a Windows game under Proton should not drag the Deck's speaker path down to the minimum quantum, and/or the speakers should not crackle at quantum 256. Shared-mode streams opening at Windows' 10 ms default would avoid it.

Not yet tested: whether a native Linux client at quantum 256 crackles on the speakers too (e.g. pw-play --latency=256/48000). If it does, the fault is in the speaker path itself. If not, it's in the period Proton picks.

Steps for reproducing this issue:
  1. On a Steam Deck LCD in Game Mode, run a Windows game that plays audio through WASAPI shared mode under Proton 11, on the internal speakers.
  2. Over ssh, run pw-top: the game's stream and the Speaker sink show QUANT 256 (512 after the game exits). Listen: intermittent clicks and crackle.
  3. Add PULSE_LATENCY_MSEC=60 %command% to the game's launch options and run it again: the sink stays at 512 and the crackle is gone.
Lingua principale
Nessun dato sulla lingua
Stelle
2.7k
Fork
89
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ValveSoftware/SteamOS

Tutte le issue di ValveSoftware/SteamOS

Issue simili

Altre issue su Audio/Video & RTC

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.