Cómo solucionar problemas de audio en Linux en portátiles ASUS ROG

Informatec Digital » Recursos » Cómo solucionar problemas de audio en Linux en portátiles ASUS ROG

Si usas un portátil ASUS ROG con Linux y el sonido no va fino, no eres el único. Entre audio apagado, parlantes que no se detectan, Dolby Atmos sin soporte y chips Realtek rebeldes, es bastante habitual que un equipo de gama alta suene peor en Linux que en Windows. La buena noticia es que casi todos estos problemas tienen explicación y, en muchos casos, solución práctica.

En este artículo vamos a desgranar, con calma, qué tipos de fallos de audio suelen aparecer en portátiles ASUS ROG y hardware similar bajo Linux, por qué ocurren y qué puedes hacer para arreglarlos o, al menos, minimizar el dolor. También veremos qué está haciendo la comunidad del kernel para mejorar la compatibilidad con equipos modernos como el ASUS ROG Ally X, y qué alternativas tienes cuando el chip de sonido integrado se convierte en un quebradero de cabeza continuo.

Problemas típicos de audio en ASUS ROG con Linux

En portátiles ASUS ROG y hardware cercano (handhelds, placas ROG, etc.) se repiten una serie de patrones. Los síntomas pueden variar muchísimo: desde no oír absolutamente nada hasta un sonido metálico, volumen bajísimo o ruido eléctrico constante. Conviene identificar bien el tipo de problema, porque la solución suele ser distinta en cada caso.

Uno de los fallos más curiosos que algunos usuarios han descrito es el siguiente: al bajar el volumen el sonido no se hace realmente más bajo, sino que se vuelve “apagado” o “subacuático”, como si se le pusiera un filtro raro, mientras que los sonidos del sistema se siguen oyendo perfectamente claros y no se ven afectados por el cambio de volumen. Es decir, cambiar el volumen no reduce la intensidad, sino la calidad.

En otros casos el problema es más clásico: no hay sonido ni por los altavoces integrados ni por los auriculares, aunque el mismo equipo, en Windows, funciona sin el menor problema. Esto se ve, por ejemplo, en algunos portátiles ASUS con procesadores AMD Ryzen (como un UM433D con Ryzen 5 3500U), donde Linux detecta el hardware en comandos como lspci y aplay -l, pero PipeWire o PulseAudio no terminan de usar correctamente el códec integrado tipo ALC294.

También aparece el escenario intermedio: Linux sí reproduce sonido, pero con una calidad muy pobre, volumen muy bajo o un timbre “metálico”. Esto es habitual en portátiles modernos con sistemas de audio avanzados (Dolby Atmos, varios altavoces, woofers dedicados, amplificadores inteligentes, etc.), como la ASUS ROG Zephyrus G14, donde el sistema detecta solo una parte de la configuración real de altavoces o no aplica los perfiles DSP propietarios que sí se cargan en Windows.

Finalmente, en placas base ROG de sobremesa con chips como el Realtek ALC1220, otro problema recurrente es la aparición de ruido eléctrico constante en los auriculares, chasquidos y, en ocasiones, incluso cuelgues del sistema cuando se usa el audio integrado bajo Linux. En Windows, al instalar el driver oficial de la placa, el ruido desaparece, mientras que en Linux el soporte del códec aún no está tan pulido en determinadas combinaciones de chipset y kernel.

El papel de ALSA, PulseAudio y PipeWire en la calidad del sonido

Cuando el audio se comporta de forma extraña al tocar el volumen, muchas veces el problema no está en el hardware en sí, sino en cómo se gestionan los distintos canales de mezcla entre ALSA y la capa de sonido de usuario (PulseAudio o PipeWire). En algunos portátiles ASUS, bajar el volumen del “canal maestro” o de los altavoces en ALSA provoca esa sensación de sonido amortiguado, mientras que ajustar solo el volumen PCM ofrece una reducción real de volumen manteniendo la claridad.

Una solución práctica que ha funcionado muy bien en un caso real de portátil con Linux fue: dejar el canal “Master” y el canal de altavoces al 100% en alsamixer, y ajustar únicamente el volumen PCM. De esa forma, el mezclador por software maneja el volumen sin degradar la señal, evitando ese efecto “sumergido” al bajar el nivel.

Para poder hacer esto necesitas tener instalado el paquete de utilidades ALSA. En distribuciones basadas en Arch, por ejemplo, basta con ejecutar:

sudo pacman -S alsa-utils

Con eso podrás abrir alsamixer desde la terminal, revisar qué canales hay disponibles y asegurarte de que tanto el canal maestro como los de altavoces están al 100%. Después, dejas que el control de volumen gráfico (o las teclas de volumen del portátil) modifiquen solo el canal adecuado, normalmente PCM o el volumen general de la “sink” de PulseAudio/PipeWire.

En entornos más modernos con PipeWire, otra técnica que puede marcar la diferencia es usar un módulo de remapeo. Por ejemplo, un usuario consiguió una mejora muy clara cargando un módulo de “remap sink” que apunta directamente al dispositivo ALSA real y crea una nueva salida lógica “PCM” sobre la que ajustar el volumen:

pactl load-module module-remap-sink sink_name=PCM master=alsa_output.pci-0000_00_1f.3.analog-stereo channels=2

Tras hacerlo, conviene reiniciar los servicios de PipeWire a nivel de usuario:

systemctl --user restart pipewire pipewire-pulse wireplumber

Después de este reinicio, el flujo recomendado fue entrar en alsamixer, poner todos los canales al máximo y, a partir de ahí, usar en el escritorio la nueva salida de audio remapeada (“remapped alsa…”) como dispositivo principal. En KDE Plasma 6, por ejemplo, se puede hacer clic derecho en el icono de volumen de la bandeja, entrar en “Configurar dispositivos de audio” y seleccionar la salida que empieza por “remapped alsa…”. De este modo, tanto las teclas de volumen del teclado como el icono del panel ajustan únicamente el volumen PCM, manteniendo la señal hardware al máximo sin distorsiones raras.

En otros entornos de escritorio el proceso es parecido, aunque las rutas de menús cambian un poco. Lo importante es entender la lógica: no siempre interesa bajar el volumen directamente en el control hardware de ALSA; a veces es mejor dejarlo a tope y controlar todo en la capa de mezcla de PipeWire/PulseAudio.

ASUS ROG Ally X y el esfuerzo de la comunidad Linux

La familia ASUS ROG no se limita a portátiles; también incluye dispositivos tipo handheld como el ASUS ROG Ally X, muy popular entre jugadores que quieren un PC de mano orientado a juegos. En el caso de este equipo, la comunidad de desarrolladores del kernel de Linux lleva tiempo trabajando para pulir los problemas de audio que aparecían al instalar distribuciones Linux en lugar de Windows.

El empujón fuerte a estas correcciones llegó a principios de 2026, cuando empezaron a acumularse reportes de usuarios sobre fallos en el subsistema de sonido del Ally X con sistemas basados en Linux. Los síntomas incluían desde ausencia total de audio hasta comportamientos erráticos en juegos y aplicaciones multimedia, algo que en un dispositivo pensado para jugar resulta totalmente inaceptable.

Para solventar estos fallos, contribuyentes del kernel han ido preparando parches específicos para el controlador de audio del Ally X, con el objetivo de que el hardware funcione correctamente en distribuciones populares como Ubuntu, Fedora, SteamOS y otras variantes orientadas a gaming. Este proceso no es trivial: implica ingeniería inversa, análisis de cómo se inicializa el dispositivo bajo Windows y prueba constante de nuevas versiones del kernel.

Medios especializados como Phoronix, dirigido por Michael Larabel, han sido de los primeros en detallar este trabajo. Han contado cómo, mediante ajustes continuos en el código del kernel y pruebas en múltiples escenarios, la experiencia de audio en el Ally X se va acercando poco a poco a lo que los usuarios esperan de un hardware tan reciente. Y no solo se trata de que “suene”; también hay que gestionar bien perfiles de energía, latencias y compatibilidad con diferentes APIs de audio usadas por los juegos.

Todo esto refleja un patrón típico en el ecosistema Linux: cada vez que aparece un nuevo gadget de hardware puntero, el soporte no siempre está listo el primer día. En muchos casos, la compatibilidad total depende de meses de trabajo por parte de desarrolladores voluntarios y empresas interesadas en que ese hardware gane presencia en el mundo del software libre.

En mercados como el brasileño, donde el Ally X ha ganado muchos fans que también son aficionados a sistemas abiertos, estos avances son especialmente importantes. Una handheld como el Ally X se vuelve realmente interesante cuando puede funcionar sin estar atada exclusivamente a Windows, permitiendo a los usuarios elegir la distribución Linux que prefieran para jugar o para uso general.

Aunque los parches de audio para el Ally X están encaminados a integrarse de forma amplia en el primer trimestre de 2026, la recomendación para usuarios menos avanzados es esperar a que las distribuciones incluyan estas correcciones de manera estable. Instalar kernels experimentales o aplicar parches manualmente tiene su riesgo, así que si el dispositivo es tu máquina principal de juegos, puede ser más prudente aguardar a que la solución “llegue por sí sola” vía actualizaciones oficiales.

Portátiles ASUS con Ryzen y códecs Realtek: detección sin sonido

En la gama de portátiles ASUS con procesadores AMD Ryzen, otro patrón bastante habitual es el de distribuciones que detectan la tarjeta de sonido pero no reproducen nada. Un ejemplo claro es el de un ASUS UM433D con Ryzen 5 3500U, en arranque dual con Windows y Linux Mint.

En este caso en concreto, el usuario probó varias distribuciones. Con Xubuntu, la instalación transcurrió sin problemas, pero no había audio en absoluto, pese a que versiones anteriores de la misma distro sí funcionaban. Pop!_OS tampoco sacó sonido siquiera en el “live” de prueba. Linux Mint, por su parte, no ofrecía audio en el modo live, pero curiosamente sí empezó a funcionar justo después de la instalación en disco.

La alegría duró poco. Tras instalar una batería de aplicaciones habituales (Discord, GIMP, Conky, etc.) y actualizar el sistema con el actualizador gráfico de Mint, el sonido volvió a desaparecer, tanto en altavoces como en auriculares. Incluso se intentó instalar PulseAudio en lugar de las herramientas por defecto, sin éxito. En Windows, en cambio, el audio seguía funcionando sin ninguna pega.

Si nos fijamos en los comandos de diagnóstico, lspci mostraba un coprocesador de audio AMD (ACP/ACP3X/ACP6x) y un controlador de audio HD para la familia 17h/19h. Por su parte, aplay -l listaba dos tarjetas de reproducción: una correspondiente a HDMI y otra a un códec analógico Realtek tipo ALC294. Esto indica que el hardware está siendo detectado, pero algo falla en la configuración del driver o en cómo PipeWire/PulseAudio selecciona la salida.

En situaciones así conviene revisar varios puntos: comprobar si el kernel que usa la distribución incluye el soporte más reciente para el códec en cuestión, verificar que no se esté seleccionando la salida HDMI en lugar de la salida analógica y consultar cómo ver los componentes de mi PC, probar a borrar y regenerar la configuración de usuario de PulseAudio/PipeWire, o incluso arrancar con un kernel diferente si la distro lo permite.

Cuando ni siquiera instalando PulseAudio manualmente se consigue que el sistema emita sonido, puede que estemos ante un bug concreto del kernel o de la pila de audio para esa combinación de hardware. En esos casos es muy recomendable buscar en foros de la distribución, reportar el problema con logs completos y seguir las instrucciones de los desarrolladores, ya que a menudo se necesitan parches específicos o ajustes en los parámetros del módulo de audio del kernel para chips AMD + Realtek relativamente nuevos.

Zephyrus G14, Dolby Atmos y el engaño del audio avanzado

Los portátiles gaming de gama alta como la ASUS ROG Zephyrus G14 (GA403WR-XS97) traen sistemas de audio muy sofisticados en Windows: varios altavoces, woofers de doble fuerza, tweeters, amplificadores inteligentes, cancelación de ruido por IA, certificaciones Hi-Res y, sobre todo, perfiles de sonido Dolby Atmos muy ajustados para sacar pecho en marketing.

Cuando se instala Linux en un equipo así, suele ocurrir que el sistema no reconoce correctamente el número real de altavoces ni puede aplicar los perfiles DSP propietarios. El resultado, para el usuario, es que el portátil suena “a lata”: volumen más bajo de lo esperado, falta de pegada en graves y sensación general de audio metálico o plano, incluso aunque técnicamente el sonido “funcione”.

Al revisar la salida de aplay -l en un caso real de Zephyrus G14, se veía lo siguiente: varios dispositivos HDA NVidia para HDMI, otro dispositivo HDMI de AMD/Generic y un único dispositivo analógico ALC285. Nada en esa lista sugiere un sistema de cuatro altavoces con woofers dedicados, y por defecto ALSA suele exponer una configuración estéreo simple.

Intentar replicar Dolby Atmos en Linux, a día de hoy, es bastante limitado. No existe soporte oficial completo de Dolby Atmos como en Windows, y los fabricantes no suelen liberar su software ni sus perfiles de procesamiento. Algunos usuarios han probado soluciones como Easy Effects (antes PulseEffects) o JamesDSP, añadiendo un convolucionador y cargando respuestas al impulso diseñadas para Dolby, lo que puede mejorar un poco el panorama, pero está muy lejos de igualar la experiencia de los drivers oficiales de Windows.

En la práctica, la realidad es que en este tipo de portátiles gaming se puede conseguir un sonido decente en Linux, pero es muy difícil reproducir la misma “magia” de procesamiento avanzando que se obtiene con el conjunto de drivers + software propietario del fabricante. Para los que sean muy maniáticos con el audio, lo más sensato es asumir que Linux ofrecerá un perfil más sencillo y apoyarse en herramientas de ecualización, compresores y efectos en PipeWire para ajustar el sonido lo mejor posible.

Chips Realtek conflictivos en placas ROG de sobremesa

Los problemas de audio en hardware ASUS ROG no se limitan a los portátiles. En placas base de sobremesa, como una ASUS ROG Strix X370-F Gaming con el chip Realtek ALC1220, también se han detectado incompatibilidades notables con Linux. En un caso documentado, el usuario, con más de una década usando GNU/Linux, se encontró por primera vez con un chip de sonido que sencillamente no funcionaba bien, más allá de la mera calidad.

Con distintas distribuciones y kernels (desde versiones con Linux 4.13 hasta snapshots de openSUSE Tumbleweed con 4.14), el comportamiento se repetía: ruido eléctrico que se colaba al reproducir algo, y ruido constante por el auricular izquierdo incluso cuando no se estaba reproduciendo nada. Además, se sospecha que el chip pudo llegar a provocar algún cuelgue del sistema.

Para descartar un fallo físico, se instaló Windows 10 en un disco aparte. Con el driver genérico de Windows aparecía el mismo problema, pero al instalar los controladores oficiales de la placa base, el ruido desaparecía y la calidad de sonido pasaba a ser bastante buena para ser Realtek. Esto apunta claramente a un tema de soporte de driver, más que a un defecto de hardware.

Aunque Realtek ALC1220 está teóricamente soportado desde Linux 4.11, la combinación de este códec con ciertas placas AMD parece seguir dando quebraderos de cabeza. Si hablamos de una máquina de producción en la que no conviene ir probando kernels experimentales, la opción de ir actualizando el núcleo hasta dar con una versión que lo soporte perfectamente no siempre es viable.

En este contexto, el autor de esa experiencia plantea una solución que en el mundo Linux a veces se mira con recelo pero que, siendo realistas, tiene todo el sentido: comprar una tarjeta de sonido dedicada y deshabilitar el chip integrado en la BIOS. Cuando la estabilidad y la limpieza de sonido importan más que exprimir al máximo el hardware integrado, es una alternativa muy razonable.

Tarjetas de sonido alternativas cuando el integrado no da la talla

Si tu chip de sonido integrado (por ejemplo, un Realtek ALC1220 en una placa ROG) da problemas continuos y no puedes permitirte estar trasteando con kernels, módulos y parches, pasarte a una tarjeta de sonido dedicada compatible con Linux puede ahorrarte muchísimo tiempo y dolores de cabeza. Aquí entran varias opciones, según el tipo de equipo y el nivel de exigencia de calidad.

Solución temporal o para portátiles: tarjeta de sonido USB

En portátiles no hay posibilidad de montar una tarjeta interna PCIe clásica, así que la salida más práctica es usar una tarjeta de sonido externa por USB. También es una buena solución temporal para sobremesas cuando no te apetece abrir la caja o quieres probar algo rápido antes de una inversión mayor.

Una opción bastante extendida y económica es la Creative Sound Blaster Play! 2. Se puede encontrar por un rango de precios que ronda los 21-28 euros en tiendas como Amazon, y diversas experiencias de usuarios indican que funciona correctamente bajo Linux. Para el caso de un chip Realtek problemático, esta pequeña tarjeta USB puede ser un salvavidas mientras decides si más adelante das el salto a una solución interna más seria.

Solución “definitiva” básica: ASUS Xonar DSX

Si estás en un sobremesa y lo que buscas es que el ordenador simplemente suene bien sin aspirar a la perfección audiófila, una buena candidata es la ASUS Xonar DSX. Cuesta en torno a 51 euros en Amazon y se ha ganado una buena fama entre usuarios de Linux como sustituta del audio integrado conflictivo.

Uno de sus puntos fuertes es que funciona “out of the box” en Linux: la conectas a una ranura PCIe, enciendes el equipo y el sistema la reconoce sin dramas. La calidad de sonido es aceptable, con algún chasquido muy puntual si se combinan volúmenes muy altos en el sistema y en ciertas aplicaciones, pero en general ofrece una experiencia muy superior a la de un chip integrado problemático.

Para los que buscan mejor calidad: ASUS Xonar DX

Para usuarios que dan más importancia a la calidad de sonido, otra tarjeta interna interesante es la ASUS Xonar DX, una veterana con casi una década a sus espaldas pero todavía muy bien valorada. Su precio ronda los 70 euros, por lo que resulta más cara que la DSX, pero a cambio ofrece una calidad de audio notablemente superior.

Según pruebas publicadas en sitios dedicados a Linux, la Xonar DX proporciona una reproducción muy limpia, con soporte inmediato en Linux también “out of the box”. Eso sí, a diferencia de la DSX, la DX requiere alimentación directa desde la fuente de alimentación (mediante un conector adicional), algo a tener en cuenta al montar el equipo.

En definitiva, tanto la Xonar DSX como la Xonar DX son opciones sólidas para sustituir a un chip Realtek conflictivo y olvidarse de ruidos eléctricos, chasquidos o inestabilidad en Linux. La elección entre una y otra dependerá de cuánto te importe la calidad fina de sonido y de tu presupuesto.

Ajustar volúmenes en ALSA cuando la nueva tarjeta suena bajo

Un detalle que desconcierta a muchos cuando pasan de un chip Realtek a una tarjeta dedicada (interna o USB) es que, a veces, el volumen general se percibe muy bajo pese a tener el control de volumen del escritorio al máximo. Esto suele deberse a cómo ALSA interpreta la salida de altavoces y el canal maestro.

En algunos casos, ALSA trata la salida de altavoces como si fuera una salida de auriculares independiente del canal maestro, dejando este último muy bajo por defecto. La solución es sencilla: entrar en alsamixer y subir el volumen del canal maestro a tope. Puedes hacerlo así desde la terminal:

alsamixer

Una vez dentro, solo tienes que moverte con las teclas de dirección entre los distintos controles, localizar “Master” (y otros canales relevantes) y subirlos al 100%. Después, ya podrás usar el control de volumen gráfico de tu entorno de escritorio para ajustar el nivel diario sin que se quede corto.

Deshabilitar el chip Realtek en la BIOS para evitar conflictos

Cuando ya has optado por una tarjeta de sonido alternativa que sabes que funciona en Linux, mantener activo el chip integrado puede causar conflictos innecesarios: el sistema puede seleccionar la salida equivocada, algunas aplicaciones pueden usar el dispositivo Realtek en lugar de la nueva tarjeta, y en general se complica el diagnóstico de posibles problemas.

Por eso suele ser muy recomendable desactivar el chip de audio Realtek en la BIOS de la placa base. El procedimiento concreto varía según el modelo, pero en general se resume en:

1. Reiniciar el equipo y entrar en la BIOS pulsando la tecla correspondiente (en muchas placas ASUS es Supr/Delete durante el arranque).
2. Pasar al modo avanzado si la BIOS arranca en modo sencillo (habitualmente con la tecla F7).
3. Buscar el apartado de “Integrated peripherals” o “Onboard devices configuration” (el nombre puede variar).
4. Localizar la opción relacionada con el controlador de audio integrado (Realtek, HD Audio, USB Audio, etc.) y ponerla en “Disabled”.
5. Guardar cambios y salir (normalmente con F10).

Tras hacer esto, Linux solo verá la nueva tarjeta de sonido, simplificando mucho la configuración y evitando que el sistema se líe entre múltiples dispositivos de salida.

Una vez entendido todo este panorama, la realidad es que el audio en portátiles ASUS ROG y hardware similar bajo Linux es un campo donde confluyen drivers del kernel aún inmaduros, códecs Realtek caprichosos, tecnologías propietarias como Dolby Atmos que no tienen equivalente directo en el mundo abierto y, por supuesto, configuraciones de ALSA/PipeWire que no siempre vienen bien afinadas de serie. Ajustar canales en alsamixer, usar sinks remapeadas, esperar a que lleguen parches para dispositivos recientes como el ROG Ally X o incluso apostar por una tarjeta de sonido dedicada son caminos distintos que, combinados con un poco de paciencia, permiten que un equipo que inicialmente sonaba fatal termine ofreciendo un audio más que digno en Linux, sin renunciar a la libertad del sistema operativo que quieres usar.