Steam Deck HDMI: alsa-card0.conf re-adds `api.alsa.period-size = 256`, forcing 1.33 ms graph cycles for HDMI passthrough

Abierto Apto para principiantes
  • ¿Algo no está bien?
#3,037 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
70/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
linux
Área
operating-systems

Línea de trabajo

Lee /usr/share/wireplumber/hardware-profiles/valve-jupiter/wireplumber.conf.d/alsa-card0.conf y el archivo correspondiente de valve-galileo; compara su configuración HDMI con el historial citado en el issue. Comprueba cómo se comportan el período del sink HDMI y el quantum del grafo durante el passthrough, usando los comandos indicados pw-top y pw-cli. El trabajo estará terminado cuando la configuración de período fijo no esté en ninguno de los dos perfiles y el passthrough ya no use el ciclo forzado de 256 frames.

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

Descripción

Your system information
  • Steam client version: not recorded (the line is in steamdeck-dsp, an OS package)
  • SteamOS version: 3.9.5 (build 20261023.100)
  • Opted into Steam client beta?: Yes
  • Opted into SteamOS beta?: Yes
  • Have you checked for updates in Settings > System?: No. The deck is held on 3.9.5 for kernel testing; steamdeck-dsp 1.03-1 is still the newest package on Valve's source mirror (checked 2026-11-03).
  • Steam Deck LCD (jupiter), kernel 7.2.7-valve2-2-neptune-72
  • steamdeck-dsp 1.03, pipewire 1:1.6.8-1.7, wireplumber 0.5.18. First measured on SteamOS 3.9.2 (steamdeck-dsp 1.02-1, pipewire 1:1.6.8-1.4); unchanged after the update.
  • Steam Deck Docking Station → HDMI → LG C4 TV, TrueHD bitstream (IEC958 passthrough, 8 ch HBR at 192 kHz)
Please describe your issue in as much detail as possible:

The LCD Deck's hardware profile sets a fixed ALSA period on the HDMI/DP card: /usr/share/wireplumber/hardware-profiles/valve-jupiter/wireplumber.conf.d/alsa-card0.conf, line 18, api.alsa.period-size = 256. valve-galileo has the same line.

For PCM this barely matters: with timer-based scheduling the graph quantum follows the clock settings. For IEC958 passthrough it sets the graph cycle. In PipeWire 1.6.8 (spa/plugins/alsa/alsa-pcm.c), the iec958 format branch sets state->force_quantum = true (line 2238), and check_position_config overwrites the graph's target duration with the device period on every cycle (lines 3148-3150). So every passthrough stream runs a 256-frame cycle: 1.33 ms at 192 kHz (TrueHD, DTS-HD MA) and 5.3 ms at 48 kHz (AC3, DTS). Neither node.force-quantum nor a global clock.force-quantum in the settings metadata changes it.

That leaves a passthrough client 1.33 ms to deliver each buffer. Our player, DSVP (a native PipeWire client; https://github.com/ASIXicle/DSVP-deck, though the public repo is well behind our development build), ran its process callback at normal priority. Under 4K HEVC decode it missed that deadline: its node's xrun count climbed about 0.5/s, and the TV dropped audio audibly. We have since worked around it in the player (a real-time process callback and a lock-free buffer), so this doesn't block us. Other passthrough players face the same 1.33 ms deadline.

The line looks like an accident. From the valve-hardware-audio-processing history inside Valve's own source package (steamdeck-packages.steamos.cloud/archlinux-mirror/sources/jupiter-main/steamdeck-dsp-1.03-1.src.tar.gz):

  • f17d7e3b26 (2023-11-03, initial commit): api.alsa.period-size = 256 on the HDMI card and on the acp5x card.
  • b12855881a (2023-11-17): "Remove bug where we were stomping api.alsa.period-size, which is meant to be readonly. This fixes audio input usage over certain applications like discord." This removes the acp5x line.
  • eb980781dc (2023-11-22): "remove period_size. As talked about previously, this doesn't actually invoke any alsa ctls, and just causes source+sink enumeration over pulse to provide incorrect information about our callback size." This removes the HDMI line. Around the same time, a user in #1254 was asked to delete this exact line.
  • 1477b278b0 (2024-03-27, "Update hardware-specific wireplumber config to new json format"): the new alsa-card0.conf for valve-jupiter and valve-galileo has api.alsa.period-size = 256 again, although the lua config it replaced no longer did.
  • The line has shipped in every steamdeck-dsp tag since 0.43, through 1.03.

Suggested fix: remove api.alsa.period-size = 256 from alsa-card0.conf in valve-jupiter and valve-galileo. That restores the 2023-11-22 state. With the property unset, PipeWire 1.6.8 sizes a passthrough period from the graph's requested quantum when the stream opens (alsa-pcm.c 2430-2441). We have not tested the deletion itself; we tested changing the property at runtime (below).

Steps for reproducing this issue:
  1. Play a TrueHD (or AC3) track with HDMI bitstream passthrough through PipeWire, to a TV or receiver that accepts it.
  2. pw-top shows the HDMI sink at QUANT 256, RATE 192000 (TrueHD): 
    R   92    256 192000  35.7us   5.9us  0.03  0.00  1840 IEC958 Tr 192000 alsa_output.pci-0000_04_00.1.hdmi-stereo-extra2
  3. pw-cli enum-params <sink id> Props lists api.alsa.period-size as Int 256.
  4. pw-cli set-param <sink id> Props '{ params = [ "api.alsa.period-size" 4096 ] }'. Then restart the passthrough stream so the sink re-opens. pw-top now shows the sink at QUANT 4096: 
    R   92   4096 192000 106.9us 239.9us  0.01  0.01  1840 IEC958 Tr 192000 alsa_output.pci-0000_04_00.1.hdmi-stereo-extra2
  5. Undo with systemctl --user restart wireplumber.
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 Operating Systems

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.