Linux 7.4 arregla audio linux apple silicon audio
En pocas palabras: Linux 7.4 soluciona el audio en Apple Silicon implementando GPIO compartido para los codecs TAS2764 y TAS2770. Esto elimina parches manuales de Asahi, estabiliza la suspensión y resuelve el problema de apagado total al suspender un altavoz individual.
Linux 7.4 incorpora soporte nativo de GPIO compartido para resolver el “imposible” power management del audio en Apple Silicon, eliminando los parches manuales de Asahi Linux y estabilizando la suspensión/resume de los codecs TAS2764 y TAS2770.
En este artículo:
- En 30 segundos
- ¿Cuál es el problema técnico del ‘power management imposible’ en Apple Silicon?
- ¿Cómo soluciona Linux 7.4 esto con la infraestructura de GPIO compartido?
- ¿Qué cambios específicos hizo James Calligeros en el código del driver?
- ¿Qué implica esto para los usuarios de Asahi Linux actualmente?
- ¿Cuándo llegará esta actualización al kernel estable?
- Qué está confirmado vs qué no
- Errores comunes al configurar audio en Mac con Linux
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- El problema técnico: Todos los altavoces comparten una línea GPIO; al suspender uno, se apagan todos antes de guardar estado, rompiendo el sistema.
- La solución en Linux 7.4: Se usa la nueva infraestructura de GPIO compartido (shared GPIO) para que múltiples drivers gestionen la misma línea sin conflictos.
- Cambio clave en código: James Calligeros modificó la inicialización de estado (de alto a bajo) para que el “default state” funcione correctamente con los drivers TAS2764/2770.
- Impacto en Asahi Linux: Se elimina el hackear de la API regulator, limpiando el kernel mainline y mejorando la estabilidad a largo plazo.
- Disponibilidad: Los parches están en cola para el ciclo de desarrollo de Linux 7.4.
Si alguna vez intentaste correr Linux en una Mac M1 o M2, sabés que el audio era un dolor de cabeza constante. No es que no funcionara, sino que se comportaba como un niño caprichoso: andaba bárbaro hasta que querías suspender la máquina. Ahí todo se caía. La nota de Phoronix del 4 de septiembre de 2026 confirma que Linux 7.4 viene a poner orden en este desastre histórico mediante el soporte nativo de audio en Apple Silicon con GPIO compartido.
Asahi Linux es el proyecto comunitario que permite ejecutar Linux en procesadores Apple Silicon. Durante años, sus desarrolladores tuvieron que ingeniar workarounds complejos porque el hardware de Apple está diseñado para macOS, no para la flexibilidad del kernel de Linux. El problema central radicaba en cómo los chips manejan la energía de los componentes de audio.
¿Cuál es el problema técnico del ‘power management imposible’ en Apple Silicon?
En las Macs con chip M-series, cada codec de software de los altavoces tiene su pin de apagado conectado a la misma línea GPIO física. Esto significa que si un driver baja esa línea para apagar su codec, apaga automáticamente todos los demás, incluso si todavía están activos. Es un diseño eléctrico que asume que solo hay un consumidor, algo que macOS maneja bien pero que rompe cualquier intento de gestión independiente en Linux.
Ponele que le pedís al kernel que suspenda el sistema. El primer codec en recibir la señal de “suspend” baja la línea GPIO. En ese microsegundo, todos los otros codecs se apagan. Cuando el kernel intenta luego guardar el estado de los registros de esos otros codecs para poder restaurarlos después, encuentra silencio total. Están muertos. No pueden responder. Y ahí es donde el sistema entra en pánico o simplemente deja de funcionar el audio al despertar. Te puede servir nuestra cobertura de el proyecto Omarchy para Mac.
“Esto hace que la gestión de energía sea imposible”, explicó James Calligeros, desarrollador clave de Asahi Linux, en su post técnico. “Cuando pasamos por la lista de codecs y llamamos a cada suspend/resume, la línea GPIO se afirma baja o alta por el primer codec suspendido/resumido. Esto causa problemas para los codecs subsiguientes; ya están apagados cuando intentamos cachear el estado del registro en el suspend.”
¿Cómo soluciona Linux 7.4 esto con la infraestructura de GPIO compartido?
La respuesta corta: usando la nueva arquitectura de shared GPIO que el kernel ha desarrollado. Antes, teníamos drivers que competían por el control de una línea física. Ahora, el kernel permite que múltiples consumidores compartan la misma línea GPIO de forma coordinada. Si un driver quiere bajar la línea, debe esperar a que todos los demás consumidores también quieran bajarla. Si uno solo quiere subirla, la línea queda arriba.
Fijate que esto no es magia negra, es lógica booleana aplicada al hardware. La infraestructura considera el primer cambio de estado de una línea como el “estado por defecto”. Este es el estado que la línea puede afirmar sin que todos los consumidores estén de acuerdo. Una vez establecido ese default, cualquier cambio posterior requiere consenso. Para el caso de Apple Silicon, esto significa que podemos definir claramente cuándo la línea debe estar activa para el audio y cuándo puede apagarse para ahorrar batería.
El equipo de Calligeros envió los parches esta semana para habilitar el uso de GPIO compartido para el soporte de audio en Apple Silicon. Esto supera los desafíos de ingeniería específicos de los SoCs de la serie M y el comportamiento de gestión de energía “imposible” que presionaba a los desarrolladores de Asahi Linux desde hacía años. Para más detalles técnicos, mirá nuestra comparación entre OrbStack y Multipass.
¿Qué cambios específicos hizo James Calligeros en el código del driver?
No basta con activar la función de GPIO compartido; hay que ajustar cómo los drivers interactúan con ella. Calligeros identificó que los drivers actuales para los codecs TAS2764 y TAS2770 inicializaban la línea GPIO en estado alto (activo). Esto significaba que el primer cambio sería hacia abajo (inactivo), definiendo incorrectamente el “default state” para la lógica de compartir.
La solución fue contra-intuitiva pero efectiva: cambiar la inicialización a estado bajo. Como ambos drivers extraen la línea alta explícitamente durante la prueba del codec (probe), iniciarla baja asegura que el primer cambio real sea de bajo a alto. Esto hace que el proxy de GPIO compartido se comporte exactamente como queremos: la línea se mantiene alta mientras cualquier codec necesite audio, y solo baja cuando todos han terminado.
Los tres primeros commits de esta serie implementan precisamente esto: habilitar GPIO compartido para ARCH_APPLE y modificar los drivers ASoC (ALSA System on Chip) correspondientes. Es un trabajo fino de integración, no una reescritura completa, lo cual habla bien de la madurez de la nueva infraestructura del kernel.
¿Qué implica esto para los usuarios de Asahi Linux actualmente?
Para vos, usuario final, la mejora inmediata es estabilidad. Pero el beneficio real es a mediano y largo plazo. Hasta ahora, Asahi Linux usaba un workaround sucio: abusaban de la API regulator para simular un regulador virtual que actuaba como proxy de la línea GPIO. Funcionaba, sí, pero era frágil. Cada actualización del kernel principal podía romper ese equilibrio delicado. En nuestra comparativa Apple vs Google profundizamos sobre esto.
Al migrar a la solución nativa de GPIO compartido, el código de Asahi Linux se integra mucho más limpio en el kernel mainline. Esto reduce la deuda técnica. Menos parches fuera de línea significa menos mantenimiento para los voluntarios del proyecto y una ruta más clara para que estas mejoras lleguen a distribuciones estándar como Fedora o Ubuntu en el futuro cercano.
Ojo con esto: no esperes que tu sonido mejore mágicamente hoy. Esta es una corrección arquitectónica. Lo que vas a notar es que las suspensiones y reanudaciones dejan de fallar silenciosamente o causar reinicios parciales del subsistema de audio. Es un golazo para la usabilidad diaria de Linux en hardware Apple.
¿Cuándo llegará esta actualización al kernel estable?
Según la información publicada el 4 de septiembre de 2026, los parches están en cola para el ciclo de desarrollo de Linux 7.4. Las fechas exactas de lanzamiento del kernel estable dependen del calendario de Linus Torvalds y no han sido especificadas por la fuente.
Sin embargo, recordá que tener el parche en el kernel estable no significa que tu distro te lo entregue mañana. Las distribuciones tienen sus propios ciclos de liberación. Fedora suele ser rápida, adoptando kernels nuevos casi inmediatamente. Ubuntu LTS puede tardar meses o años en incorporar features tan específicas, dependiendo de sus políticas de backporting. Para la mayoría de nosotros, la espera será de unas pocas semanas tras el lanzamiento oficial del kernel 7.4. Complementá con guía de pipelines CI/CD en 2026.
Qué está confirmado vs qué no
| Aspecto | Estado | Detalle |
|---|---|---|
| Infraestructura GPIO Compartido | Confirmado | Integrada en el kernel base, lista para uso en ARCH_APPLE. |
| Parches de Audio Apple Silicon | En Cola | Presentados por James Calligeros, dirigidos a Linux 7.4. |
| Eliminación de Workaround Regulator | Confirmado | La nueva solución reemplaza el hack anterior en Asahi. |
| Fecha Exacta de Release 7.4 | Incierto | No especificada por la fuente. |
| Soporte en Distro AR/US | Pendiente | Depende de cada mantenedor de paquete (Fedora, Arch, etc.). |
Errores comunes al configurar audio en Mac con Linux
- Ignorar los logs del kernel: Mucha gente reporta “no hay sonido” sin mirar dmesg. Fijate si ves errores de GPIO conflictivos o timeouts de I2C antes de culpar al driver.
- Usar imágenes viejas de Asahi: El soporte cambia rápido. Si estás en una build de 2025, probablemente tengas el bug de power management activo. Actualizá siempre al último nightly si buscás estabilidad experimental.
- Esperar compatibilidad perfecta con Windows: Los drivers de audio en Linux son modulares. No asumas que un plugin de volumen funcionará igual que en macOS; a veces necesitás configurar manualmente el mixer ALSA.
Preguntas Frecuentes
¿Qué mejoras trae Linux 7.4 para Apple Silicon?
Linux 7.4 introduce soporte nativo para GPIO compartido, resolviendo los fallos de suspensión y reanudación del audio en chips M-series al permitir una gestión energética correcta de los codecs TAS2764 y TAS2770.
¿Por qué era difícil gestionar la energía del audio en Mac con Linux?
Porque todos los codecs de altavoces comparten una única línea GPIO física para el apagado, lo que causaba que al intentar suspender un componente, se apagaran todos simultáneamente, corrompiendo el estado del sistema.
¿Cómo se resuelve el problema de los GPIO compartidos en Asahi Linux?
Mediante la implementación de la infraestructura de GPIO compartido del kernel mainline, que coordina múltiples drivers para que solo bajen la línea cuando todos los consumidores estén de acuerdo, eliminando la necesidad de hacks anteriores.
¿Cuándo estará disponible el soporte mejorado de audio para M-series?
Los parches están programados para el ciclo de desarrollo de Linux 7.4. La disponibilidad en tu distribución específica dependerá de sus tiempos de actualización.
Conclusión
Esta actualización no es solo un parche de bug; es un paso fundamental hacia la madurez de Linux en hardware propietario. Al integrar la solución directamente en el kernel mainline, la comunidad evita depender de forks perpetuos y hacks frágiles. Si sos dev o usuario avanzado de Asahi Linux, preparate para actualizar tu kernel apenas salga la 7.4. Vas a notar una diferencia tangible en la confiabilidad de tus sesiones de trabajo, especialmente si usás la laptop en modo suspensión frecuente. La tecnología avanza, y por fin, el audio en Apple Silicon con Linux deja de ser una apuesta arriesgada para convertirse en una opción viable.
