La distorsión de sonido en Ubuntu 24.04 puede provenir de varios componentes: la aplicación, PipeWire, WirePlumber, ALSA, el controlador del kernel o el propio hardware de audio. Lo más práctico es identificar primero el dispositivo afectado y luego modificar la configuración de un búfer o dispositivo a la vez. En un escritorio Ubuntu 24.04 estándar, PipeWire se encuentra por encima de ALSA y WirePlumber gestiona los dispositivos ALSA, por lo que la mayoría de los usuarios deberían ajustar las propiedades de ALSA expuestas a través de WirePlumber antes de reemplazar la configuración ALSA predeterminada del sistema.
Ubuntu 24.04 originalmente incluía PipeWire 1.0.4, y los paquetes Noble actuales de Ubuntu siguen utilizando WirePlumber 0.4.17 en lugar del formato de configuración 0.5 más reciente. Este detalle de la versión es importante porque WirePlumber 0.4 utiliza fragmentos de Lua ~/.config/wireplumber/main.lua.d/. La wireplumber.conf.dsintaxis más reciente que puede encontrar en la documentación oficial actual se aplica a WirePlumber 0.5 y versiones posteriores. Compruebe la versión instalada antes de copiar cualquier configuración.
Referencias oficiales: notas de la versión Ubuntu 24.04 LTS , paquete WirePlumber de Ubuntu para actualizaciones de Noble , referencia de configuración de WirePlumber 0.4 ALSA y referencia del complemento ALSA PCM .
Guía rápida: qué probar primero
| Síntoma | Primera comprobación práctica | Posible ajuste |
| Crujidos bajo carga de CPU | Confirme el fregadero correcto y esté atento a posibles interrupciones. | Pruebe con un período ALSA de mayor tamaño, como 1024 o 2048 fotogramas. |
| Distorsión solo en un DAC USB | Identifique el nodo ALSA/PipeWire exacto. | Aplique la regla solo a ese nodo; evite una regla global. |
| Ruido cuando un dispositivo sale del estado de inactividad. | Reproducir después de varios segundos de silencio | Aumentar o deshabilitar el tiempo de espera de suspensión para ese nodo específico. |
| Problemas en una aplicación heredada que solo utiliza ALSA. | Pruebe la aplicación con aplayo un PCM explícito | Utilice un por usuario ~/.asoundrccon plug/dmix |
| Distorsión a una frecuencia de muestreo | Prueba de material a 44,1 kHz y 48 kHz | Prefiera una frecuencia de hardware compatible y deje que PipeWire realice el remuestreo cuando sea necesario. |
1. Identifique el hardware ALSA y la pila de audio.
Para empezar, enumera los dispositivos de reproducción y comprueba qué servidor de audio está activo. No des por sentado que hw:0,0se trata de tus altavoces; los dispositivos HDMI, los auriculares USB, las cámaras web y las estaciones de acoplamiento pueden cambiar la numeración de la tarjeta entre arranques.
aplay -l
wpctl status
pactl info
wireplumber --version
pipewire --version
Leyenda: La aplay -llista separa el dispositivo de reproducción analógica integrado de HDMI, lo que ayuda a evitar aplicar un ajuste ALSA a la tarjeta incorrecta.
Si pactl infoaparece el mensaje "PulseAudio (en PipeWire)", es normal en Ubuntu 24.04. PipeWire proporciona la interfaz compatible con PulseAudio. En Ubuntu 24.04/Noble estándar, wireplumber --versiondebería mostrarse la serie 0.4.x, a menos que hayas instalado una compilación diferente.
2. Confirme la distorsión antes de cambiar la configuración.
Utilice una prueba reproducible en lugar de juzgar los cambios a partir de vídeos web aleatorios. Un archivo WAV corto speaker-testo una pista musical conocida facilitan las comparaciones antes/después. Compruebe también si el problema se presenta por igual en la salida analógica, HDMI, Bluetooth y USB. Si solo una ruta se ve afectada, limite la solución a esa ruta.
speaker-test -c 2 -t wav
aplay /usr/share/sounds/alsa/Front_Center.wav
Para dispositivos USB, el kernel expone información de flujo en /proc/asound/. La ruta exacta varía según la tarjeta, así que /proc/asound/cardsprimero verifique en lugar de copiar un número de tarjeta a ciegas.
Leyenda: La información de la transmisión ALSA puede revelar la frecuencia de muestreo activa, el número de canales y el formato de muestra para una transmisión de reproducción; el número de tarjeta depende del hardware.
3. Realice una copia de seguridad de la configuración de usuario actual.
Antes de editar nada, conserve cualquier modificación existente de ALSA o WirePlumber. Los cambios a nivel de usuario son más seguros que editar archivos en /usr/share, ya que las actualizaciones de paquetes pueden reemplazar archivos del sistema.
cp -a ~/.asoundrc ~/.asoundrc.backup 2>/dev/null || true
mkdir -p ~/.config/wireplumber/main.lua.d
cp -a ~/.config/wireplumber/main.lua.d ~/.config/wireplumber/main.lua.d.backup 2>/dev/null || true
Si previamente copiaste una configuración de una guía escrita para WirePlumber 0.5, elimínala o muévela a otro lugar antes de probarla en Ubuntu 24.04 estándar. WirePlumber 0.4 y 0.5 utilizan formatos de configuración diferentes.
4. Ajuste el comportamiento del búfer ALSA mediante WirePlumber 0.4.
En Ubuntu 24.04, este suele ser el ajuste más relevante a nivel de ALSA, ya que WirePlumber crea y configura los nodos PipeWire compatibles con ALSA. La documentación oficial de WirePlumber describe api.alsa.period-sizeel tamaño del período en muestras y api.alsa.headroomel almacenamiento en búfer adicional entre punteros de hardware y software. La mayoría de los dispositivos USB se tratan como dispositivos de procesamiento por lotes, y el tamaño del período afecta tanto a la frecuencia de interrupción como al comportamiento del almacenamiento en búfer.
Crear una regla de usuario:
nano ~/.config/wireplumber/main.lua.d/51-alsa-tuning.lua
Utilice una regla que se dirija únicamente al nodo de salida problemático. Primero obtenga el nombre del nodo con wpctl statuso pw-cli list-objects Node. Luego adapte este ejemplo:
local rule = {
matches = {
{
{ "node.name", "matches", "alsa_output.*" },
},
},
apply_properties = {
["api.alsa.period-size"] = 1024,
["api.alsa.headroom"] = 0,
},
}
table.insert(alsa_monitor.rules, rule)
No considere 1024 como un valor mágico universal. Es un punto de prueba conservador. Si la distorsión persiste, compare 512, 1024 y 2048 uno por uno. Los periodos más largos pueden mejorar la tolerancia a los retrasos de programación en algunos sistemas, pero aumentan la latencia; los periodos más cortos pueden reducir la latencia, pero aumentan la frecuencia de interrupciones y pueden revelar subdesbordamientos en una máquina sobrecargada. Mantenga el valor más pequeño que permanezca estable para su carga de trabajo.
Si el dispositivo tiene E/S mapeadas en memoria dañadas, WirePlumber también expone api.alsa.disable-mmap. La documentación oficial describe explícitamente esto como una solución alternativa de compatibilidad y señala que el acceso de lectura/escritura es más lento, por lo que no lo habilite a menos que la distorsión se correlacione claramente con el comportamiento de mmap.
["api.alsa.disable-mmap"] = true,
Otra opción específica del dispositivo es session.suspend-timeout-seconds... Si un DAC emite chasquidos o distorsiones cada vez que se activa, probar un tiempo de espera más prolongado, o 0deshabilitar la suspensión para ese nodo, puede ayudar a aislar la causa. Deshabilitar la suspensión mantiene el dispositivo ALSA ocupado, por lo que se trata de una compensación, no de una recomendación predeterminada.
5. Utilice .asoundrc solo cuando la aplicación realmente utilice ALSA directamente.
Un PCM por usuario ~/.asoundrcpuede ser útil para aplicaciones antiguas que omiten PipeWire y abren directamente los PCM de ALSA. También puede ser útil para probar el comportamiento de la mezcla de software o la frecuencia de muestreo fija. Sin embargo, anular el valor predeterminado de ALSA globalmente puede interferir con el complemento ALSA de PipeWire, por lo que se recomienda usar un PCM con nombre siempre que sea posible en lugar de reemplazarlo pcm.!default.
Por ejemplo, dmixel complemento de ALSA admite valores explícitos rate, period_size, y buffer_size. Un PCM de prueba con nombre puede tener este aspecto:
pcm.stable_test {
type plug
slave.pcm "stable_dmix"
}
pcm.stable_dmix {
type dmix
ipc_key 2048
ipc_key_add_uid true
slave {
pcm "hw:0,0"
rate 48000
period_time 0
period_size 1024
buffer_size 4096
}
}
Reemplazar hw:0,0con la tarjeta y el dispositivo reales de aplay -l. Luego, probar sin cambiar la configuración predeterminada del sistema:
aplay -D stable_test /usr/share/sounds/alsa/Front_Center.wav
Leyenda: Cada usuario .asoundrcpuede definir parámetros ALSA fijos para realizar pruebas controladas; hwse debe usar un destino directo con precaución, ya que omite la conversión automática de formato.
El proyecto ALSA señala que dmixtiene una configuración base fija a menos que se especifiquen valores en su definición de esclavo, mientras que el plugcomplemento puede realizar la conversión de formato y velocidad. Por eso, combinar un plugPCM con nombre con un dmixPCM ajustado por separado es más seguro para los experimentos que obligar a cada programa a abrir el hardware directamente.
6. Reinicie los servicios de audio del usuario y vuelva a realizar la prueba.
Tras modificar la regla de WirePlumber, reinicie la pila de audio del usuario. Cierre primero las aplicaciones que estén utilizando audio activamente.
systemctl --user restart wireplumber pipewire pipewire-pulse
A continuación, repita la misma prueba realizada con el mismo material. Abra Ajustes > Sonido y compruebe que el dispositivo de salida y el perfil esperados siguen seleccionados.
Leyenda: Tras reiniciar los servicios de audio, compruebe que Ubuntu sigue seleccionando el dispositivo de salida y el perfil previstos antes de determinar si se ha solucionado la distorsión.
Cómo determinar si el ajuste funcionó
- El mismo archivo de prueba se reproduce repetidamente sin crujidos, zumbidos, distorsiones ni interrupciones breves.
- La distorsión no reaparece después de que el dispositivo entra en estado de inactividad y se reactiva.
- Las aplicaciones de escritorio, los navegadores y las videollamadas habituales siguen utilizando el dispositivo de salida previsto.
- La latencia sigue siendo aceptable para su caso de uso; la reproducción de música puede tolerar más almacenamiento en búfer que la monitorización en directo o los videojuegos.
- La solución se mantiene estable después de cerrar sesión y volver a iniciarla o reiniciar el sistema.
Cuando los ajustes de ALSA no son la solución adecuada
No aumentes los búferes si el síntoma es claramente recorte de hardware, un cable suelto, una entrada analógica sobrecargada, un concentrador USB defectuoso o un altavoz en mal estado. Comprueba también los niveles del mezclador alsamixer; la distorsión que se produce solo cerca del 100 % de volumen puede estar relacionada con la ganancia en lugar de ser un problema de programación.
Si el problema surgió tras una actualización del kernel o del firmware, pruebe con otro kernel compatible desde el menú GRUB antes de crear reglas de audio cada vez más complejas. Si solo se ve afectado Bluetooth, concéntrese en el códec/perfil de Bluetooth en lugar de en la configuración del período de ALSA. Si solo se ve afectado HDMI, verifique primero el perfil HDMI y el receptor/monitor.
Lista de verificación de reversión
- Eliminar o cambiar el nombre
~/.config/wireplumber/main.lua.d/51-alsa-tuning.lua.
- Restaure
~/.asoundrcdesde la copia de seguridad o elimine el archivo de prueba.
- Reiniciar
wireplumber, pipewire, y pipewire-pulse.
- Vuelva a ejecutar el comando
wpctl statuspara speaker-testconfirmar que se ha restablecido el comportamiento predeterminado.
En resumen
Para Ubuntu 24.04, comience con reglas ALSA de WirePlumber 0.4 específicas en lugar de una sustitución general del sistema .asoundrc. Identifique el nodo de salida exacto, modifique una propiedad a la vez y compare el mismo audio de prueba después de cada cambio. Un tamaño de período de 1024 es un punto de partida razonable para el diagnóstico, pero el valor correcto depende del dispositivo y la carga de trabajo. Reserve disable-mmap, suspenda los cambios y utilice dmixPCM personalizados para los casos en que sus pruebas indiquen específicamente esos comportamientos.