- Triforce es un beamformer adaptativo basado en Rust para aprovechar el arreglo de micrófonos de las laptops con Apple Silicon también fuera de macOS
- Los dispositivos compatibles se limitan a MacBook Air y Pro de 13" con M1/M2, MacBook Air de 15" con M2, y MacBook Pro de 14" y 16" con M1/M2 Pro·Max
- Los arreglos de micrófonos triangulares o lineales de estos equipos son demasiado sensibles y omnidireccionales sin beamforming, por lo que es difícil separar la señal deseada
- La estructura busca minimizar dependencias para requerir solo LV2 además de los crates especificados en Cargo.lock
- No es realista esperar que la implementación actual supere a la de Apple, y por la ausencia de SIMD/NEON no soporta descomposición de banda ancha ni salida estéreo
Beamformer para arreglos de micrófonos de Apple Silicon
- Triforce implementa un beamformer adaptativo Minimum Variance Distortionless Response para el arreglo de micrófonos de laptops con Apple Silicon
- Los dispositivos compatibles son los siguientes
- MacBook Pro 13" (M1/M2)
- MacBook Air 13" (M1/M2)
- MacBook Pro 14" (M1 Pro/Max, M2 Pro/Max)
- MacBook Pro 16" (M1 Pro/Max, M2 Pro/Max)
- MacBook Air 15" (M2)
- El arreglo de micrófonos de las laptops objetivo está dispuesto en forma triangular o lineal
- Si se usa sin beamforming, este arreglo es demasiado sensible y funciona de forma omnidireccional, por lo que pierde utilidad; para aprovecharlo fuera de macOS se necesita un beamformer
- Además de los crates especificados en Cargo.lock, la dependencia adicional necesaria es LV2
Estado de la implementación y limitaciones conocidas
- Como es difícil encontrar bibliografía accesible sobre DSP y beamforming adaptativo de banda ancha, la implementación actual es un intento basado en matemáticas de ingeniería de nivel de primer año universitario y en principios obtenidos de varias páginas web y PDF
- Es difícil esperar que tenga mejor rendimiento que la implementación de Apple, y los parches de mejora son bienvenidos
- Las limitaciones conocidas son las siguientes
- nalgebra no realiza optimización SIMD explícita y depende de la vectorización automática de LLVM, por lo que el rendimiento y la eficiencia de las rutinas matemáticas de matrices no son buenos
- Sin soporte SIMD/NEON, es demasiado lento para un plugin de audio en tiempo real, así que no realiza descomposición de banda ancha
- La salida solo soporta mono, y el procesamiento matricial adicional para una salida estéreo falsa tiene un costo computacional demasiado alto
- Según las estadísticas de crates.io, el total de descargas es de 4,247 y hay 7 versiones publicadas
1 comentarios
Opiniones en Hacker News
El artículo del blog con contexto está aquí: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...
La Toshiba Tablet PC convertible que usaba hace más de 20 años tenía un arreglo de micrófonos con beamforming e incluía software para especificar desde dónde se quería grabar el sonido
El uso principal era grabar clases, y se podía configurar para apuntar el haz hacia el profesor, detrás de la laptop, y grabar solo el sonido de esa dirección
Era una idea sorprendente, pero no la he vuelto a ver desde entonces
También era una excelente idea, y todavía salen productos parecidos: https://electronics.sony.com/imaging/imaging-accessories/all...
El arreglo de micrófonos de la sala de reuniones identifica quién está hablando y separa el audio de esa persona
En videoconferencias de salas grandes, desde hace mucho se elegía en cada momento el micrófono con mayor volumen para evitar mezclar el ruido de varios micrófonos; al sumarle beamforming, mejora muchísimo
Si los micrófonos estaban en el plano de la pantalla y no en el cuerpo, creo que no habrían podido distinguir entre “de frente” y “justo detrás”
Podría tener varios buenos usos, como que un auto autónomo “vea” a un peatón detrás de unos arbustos, detecte antes a un vehículo de emergencia que se aproxima o escuche una bicicleta antes de verla
Siempre me pregunté cómo la implementaron
Mi tesis de maestría, que nunca terminé, trataba un tema parecido
Intentaba aprovechar que casi todos los smartphones tienen al menos 2 micrófonos para hacer estimación de posición 3D y separación de hablantes
Las lecciones que aprendí fueron estas: las tasas de muestreo entre dispositivos se desvían un poco, más o menos ±1 muestra por segundo; no es mucho, pero hay que tenerlo en cuenta
Las características espectrales de los micrófonos de consumo varían bastante, al punto de que incluso dos teléfonos del mismo modelo recién sacados de la caja tienen diferencias medibles y también audibles
El sonido se refleja en todo tipo de superficies, especialmente en paredes de concreto
De lo fácilmente accesible, el interior de un auto es lo más cercano a una cámara anecoica
La transformada de Fourier de una gaussiana es una gaussiana, así que resulta muy útil al estimar la frecuencia de señales armónicas como la voz cuando la longitud de onda es un poco menor que la mitad de la longitud de la ventana
No había nada que reflejara el sonido salvo el suelo, y quizá puso espuma debajo del experimento
Claro que eso no elimina el ruido ambiental, pero según decía funcionó bastante bien para reducir los reflejos provenientes de su propio equipo
Uno se da cuenta de cuánto trabajo hace falta, incluso en partes que parecen triviales, para lograr que Linux funcione en una Mac con Apple Silicon
Aquí uso “triviales” con el máximo respeto. Es que casi nunca se usan los micrófonos integrados, salvo que uno haya olvidado sus audífonos con micrófono
Citando el informe de avances (https://asahilinux.org/2025/03/progress-report-6-14/#is-this...): “Aun así, es Apple. Nada es simple”
Unos audífonos con micrófono tipo wraparound y brazo dedicado quizá serían mejores, pero los audífonos de uso diario están limitados por la ubicación del micrófono
El micrófono de la MBP tenía tan buena cancelación de ruido que era preferible a la mayoría de los micrófonos de brazo en headsets
También tiene la ventaja de captar menos sonidos innecesarios cerca de la boca, como masticar chicle o tomar café
Siento que el 99% de la gente en reuniones usa una combinación de audífonos normales y el micrófono de la MBP
El principal problema de esta configuración es que no puedes escuchar tu propia voz en los audífonos, lo que a veces puede ser bastante molesto si usas audífonos con cancelación de ruido
Pero Apple lleva un tiempo desviándose incluso del camino que ella misma pavimentó
El punto clave es que todo lo que Apple fabrica está integrado verticalmente
Para ofrecer funciones como AirDrop o Continuity, las implementa a lo largo de toda la pila
Si eliges el camino DIY, que es básicamente lo que busca Asahi, también tienes que crear tú mismo las piezas de software faltantes
La ventaja es que todo el ecosistema puede beneficiarse de ese trabajo. Por ejemplo, el nuevo DSP de PipeWire
El hardware de PC en general no es muy bueno, y si le quitas estos componentes adicionales, el hardware de Apple tampoco lo es
Pero el “paquete completo” ha dejado el estándar bastante alto, y me gustaría ver que el ecosistema libre y de código abierto llegue a ese nivel
Algunas de las primeras MacBook Pro Retina solo tienen arreglo de 2 micrófonos, pero la mayoría cuenta con el arreglo completo de 3 micrófonos
De lo contrario, baja a un modo de códec de bajísimo bitrate y antiquísimo, y hasta la entrada de audio que escuchas se vuelve horrible
Por eso, siempre que puedo, uso el micrófono de la Mac
Incluso en hardware de laptops barato —y, por supuesto, también en hardware de gama alta como una MBP— se pueden obtener resultados sorprendentemente buenos con técnicas de DSP por software.
Me gusta que gran parte del trabajo de audio de Asahi pueda aplicarse tal cual no solo a las Mac, sino también a laptops comunes.
Ya estoy usando en una laptop HP barata el plugin de síntesis de armónicos graves Bankstown y el ecualizador de convolución desarrollados para Asahi, y los resultados son sorprendentemente impresionantes.
Esto también usa la función de carga automática de cadenas de plugins de PipeWire desarrollada para Asahi.
Creo que este beamformer también tendrá bastantes usos fuera del ecosistema de Asahi.
En cuanto a la optimización SIMD, estaría bueno que los autores miraran faer.
Personalmente, mi experiencia con pulp, la biblioteca base, no fue muy buena porque intenta hacer cosas que van más allá del álgebra lineal; pero si el objetivo es principalmente acelerar operaciones de álgebra lineal, creo que encajaría bien.
Estoy preparando una entrada de blog y un podcast relacionado sobre SIMD en Rust, y pienso cubrir esto ahí.
[1]: https://docs.rs/faer/latest/faer/
Repositorio de GitHub: https://github.com/chadmed/triforce
Dice “los arreglos de micrófonos en las siguientes laptops Apple Silicon” y enumera MacBook Pro 13" M1/M2, MacBook Air 13" M1/M2, MacBook Pro 14" M1 Pro/Max·M2 Pro/Max, MacBook Pro 16" M1 Pro/Max·M2 Pro/Max y MacBook Air 15" M2; me pregunto si eso significa que las M2/M3 no tienen arreglos de micrófonos similares, o si simplemente no fueron probadas.
También me pregunto si esto solo es compatible con Linux.
No sé bien si también sería posible en macOS, ni si Apple proporciona streams dedicados para cada micrófono.
macOS realiza internamente cálculos de beamforming muy similares y solo muestra al usuario un micrófono unificado.
M3 todavía no está soportado por Asahi Linux, así que el hecho de que no aparezca en la lista es independiente de si M3 tiene o no esos micrófonos.
macOS tiene su propio software que maneja esto en capas profundas del sistema, y a las aplicaciones solo se les expone como un micrófono normal.
En el reporte de avances más reciente de Asahi Linux hay una discusión más general.
“Por desgracia, los micrófonos PDM son muy omnidireccionales y muy sensibles. No hay forma de convivir con ellos sin algún tipo de beamforming”.
https://asahilinux.org/2025/03/progress-report-6-14/
Además, resultó que parte del trabajo hecho antes para la salida de los parlantes se reutilizó también para la entrada de micrófono.
“Gracias a la base que habíamos preparado en PipeWire y WirePlumber para el soporte de parlantes, conectar cadenas DSP, incluida Triforce, a los micrófonos fue realmente sencillo. ¡Solo hubo que actualizar los archivos de configuración y dejar que WirePlumber hiciera el resto!”
Sobre la frase “al igual que con los parlantes, Apple intenta lucirse demasiado aquí”, sería muy interesante que el autor de este paquete diera su opinión.
En particular, me da curiosidad qué piensa sobre la implementación de los parlantes.
¿Qué es lo excesivamente complejo? ¿El hardware o el software?
Como usuario de MBP y aficionado al audio, la implementación de los parlantes, sobre todo en los modelos MBP más grandes, me pareció realmente impresionante.
Pero soy solo aficionado, y aparte de los tweeters y la configuración de woofers duales opuestos, no sé mucho más.
Parece que Apple también usa trucos como los ecualizadores adaptativos que emplean los diseñadores de “buenos” parlantes Bluetooth para sacar un rendimiento decente y extensión de graves de parlantes pequeños.
Uno de los problemas es que se necesita DSP sofisticado para limitar el consumo de energía y evitar el sobrecalentamiento.
Sin eso, el volumen que puede obtenerse dentro de los límites de seguridad es muy limitado.
Si quieres saber más, probablemente este sea el mejor resumen: https://github.com/AsahiLinux/asahi-audio
Eso ha sido cierto durante varias generaciones.
Cuando usaba una MBP de 2014, al ver películas de viaje varios amigos se sorprendían con el sonido.
Con la MBP M4 pasa lo mismo: la calidad de los parlantes está en un nivel que, en la práctica, es incluso más de lo necesario.
Hoy en día, al menos en hardware premium, el “audio espacial” en parlantes y los micrófonos con beamforming empiezan a sentirse como el estándar.
El audio torpe, ruidoso, apretado y mal balanceado ya no pasa.