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

Abierto
  • ¿Algo no está bien?
#3,017 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
linux
Área
audio-video-rtc, game-dev

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Sin datos de lenguaje
Estrellas
2.7k
Forks
89
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ValveSoftware/SteamOS

Todos los issues de ValveSoftware/SteamOS

Issues similares

Más issues de Audio/Video & RTC

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.