- Triforce est un beamformer adaptatif basé sur Rust, conçu pour exploiter la matrice de micros des ordinateurs portables Apple Silicon en dehors de macOS
- La prise en charge est limitée aux MacBook Air/Pro 13" M1/M2, au MacBook Air 15" M2, ainsi qu’aux MacBook Pro 14"/16" M1/M2 Pro·Max
- Les matrices de micros triangulaires ou linéaires de ces appareils sont trop sensibles et omnidirectionnelles sans beamforming, ce qui rend difficile l’isolation du signal souhaité
- La structure vise à minimiser les dépendances afin de ne nécessiter que LV2, en plus des crates indiquées dans
Cargo.lock - L’implémentation actuelle ne peut pas raisonnablement être considérée comme supérieure à celle d’Apple et, en l’absence de SIMD/NEON, ne prend pas en charge la décomposition large bande ni la sortie stéréo
Beamformer pour matrices de micros Apple Silicon
- Triforce implémente un beamformer adaptatif Minimum Variance Distortionless Response pour les matrices de micros des ordinateurs portables Apple Silicon
- Les appareils pris en charge sont les suivants
- 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)
- Les matrices de micros des ordinateurs portables visés sont disposées en configuration triangulaire ou linéaire
- Sans beamforming, ces matrices sont trop sensibles et fonctionnent de manière omnidirectionnelle, ce qui limite leur utilité ; un beamformer est donc nécessaire pour les exploiter en dehors de macOS
- En plus des crates spécifiées dans
Cargo.lock, la seule dépendance supplémentaire requise est LV2
État de l’implémentation et limites connues
- Comme il est difficile de trouver une documentation accessible sur le DSP et le beamforming adaptatif large bande, l’implémentation actuelle est une tentative fondée sur des mathématiques de l’ingénieur de niveau première année de licence et sur des principes tirés de diverses pages web et PDF
- Il est difficile d’espérer de meilleures performances que l’implémentation d’Apple, et les patchs d’amélioration sont les bienvenus
- Les limites connues sont les suivantes
- nalgebra n’effectue pas d’optimisation SIMD explicite et s’appuie sur l’auto-vectorisation de LLVM, ce qui nuit aux performances et à l’efficacité des routines de calcul matriciel
- Sans prise en charge SIMD/NEON, c’est trop lent pour un plugin audio temps réel, donc il n’y a pas de décomposition large bande
- Seule la sortie mono est prise en charge, car le traitement matriciel supplémentaire nécessaire à une fausse sortie stéréo est trop coûteux en calcul
- D’après les statistiques de crates.io, le nombre total de téléchargements est de 4 247 et 7 versions ont été publiées
1 commentaires
Avis de Hacker News
L’article de blog avec le contexte est ici : https://asahilinux.org/2025/03/progress-report-6-14/#is-this...
Il y a plus de vingt ans, les convertibles Toshiba Tablet PC avaient un réseau de microphones avec beamforming, ainsi qu’un logiciel permettant d’indiquer d’où enregistrer le son
L’usage principal était l’enregistrement de cours, et on pouvait orienter le faisceau vers le professeur, derrière l’ordinateur portable, pour ne capter que le son venant de cette direction
C’était une idée formidable, mais je ne l’ai plus revue depuis
C’était aussi une excellente idée, et des produits similaires existent encore : https://electronics.sony.com/imaging/imaging-accessories/all...
Le réseau de micros d’une salle de réunion détermine qui parle et isole l’audio de cette personne
Les grandes salles de visioconférence choisissent depuis longtemps, à chaque instant, le micro le plus fort parmi plusieurs afin d’éviter de mélanger le bruit de tous les micros ; avec du beamforming en plus, c’est bien meilleur
Si les micros étaient dans le plan de l’écran plutôt que dans le châssis, j’ai l’impression qu’ils n’auraient pas pu distinguer « devant » de « juste derrière »
Cela pourrait avoir beaucoup de bons usages, par exemple permettre à une voiture autonome de « voir » un piéton derrière des buissons, de détecter plus tôt un véhicule d’urgence qui approche, ou d’entendre un vélo avant de le voir
Je me suis toujours demandé comment ils l’avaient implémentée
Mon mémoire de master, que je n’ai finalement jamais terminé, portait sur un sujet similaire
J’essayais d’exploiter le fait que presque tous les smartphones ont au moins deux micros pour faire de la localisation 3D et de la séparation de locuteurs
Les leçons que j’en ai tirées sont les suivantes : les taux d’échantillonnage varient légèrement d’un appareil à l’autre, autour de ±1 échantillon par seconde, ce qui n’est pas énorme mais doit être pris en compte
Les caractéristiques spectrales des micros grand public varient beaucoup ; même deux téléphones du même modèle à peine sortis de leur boîte présentent non seulement des différences mesurables, mais aussi audibles
Le son se réfléchit partout, en particulier sur les murs en béton
Parmi les endroits facilement accessibles, l’intérieur d’une voiture est ce qui se rapproche le plus d’une chambre anéchoïque
La transformée de Fourier d’une gaussienne étant une gaussienne, elle est très utile pour estimer la fréquence de signaux harmoniques comme la voix lorsque la longueur d’onde est un peu inférieure à la moitié de la longueur de la fenêtre
À part le sol, il n’y avait rien sur quoi le son puisse se réfléchir, et il avait peut-être placé de la mousse sous l’expérience
Bien sûr, cela ne supprime pas le bruit ambiant, mais il disait que cela fonctionnait assez bien pour réduire les réflexions provenant de son propre matériel
On se rend compte de la quantité de travail nécessaire pour faire tourner Linux sur un Mac Apple Silicon, même pour des aspects qui semblent mineurs
Ici, « mineur » est dit avec le plus grand respect : je n’utilise presque jamais les micros intégrés, sauf si j’ai oublié mon casque
Pour citer le rapport d’avancement (https://asahilinux.org/2025/03/progress-report-6-14/#is-this...) : « Mais c’est Apple. Rien n’est simple »
Un casque-micro tour de tête avec une perche dédiée ferait peut-être mieux, mais les écouteurs du quotidien sont limités par l’emplacement du micro
Le micro du MBP avait même une bonne réduction de bruit, au point que je le préférais à la plupart des micros à perche de casques
Il a aussi l’avantage de moins capter les sons indésirables près de la bouche, comme mâcher un chewing-gum ou boire du café
J’ai l’impression que 99 % des gens en réunion utilisent un casque ordinaire avec le micro du MBP
Le principal problème de cette configuration est qu’on ne s’entend pas soi-même dans le casque, ce qui peut parfois être assez gênant avec un casque à réduction de bruit
Cela dit, Apple s’écarte depuis un certain temps même de la voie qu’elle avait elle-même défrichée
Le point essentiel est que tout ce qu’Apple fabrique est intégré verticalement
Pour proposer des fonctions comme AirDrop ou Continuity, l’implémentation traverse toute la pile
Si l’on choisit la voie DIY, c’est-à-dire en pratique celle qu’Asahi vise, il faut aussi créer soi-même les morceaux logiciels manquants
L’avantage est que tout l’écosystème peut bénéficier de ce travail. Le nouveau DSP de PipeWire en est un exemple
Le matériel PC est globalement assez médiocre, et sans ces composants supplémentaires, le matériel Apple l’est aussi
Mais « l’ensemble complet » a placé la barre assez haut, et j’aimerais voir l’écosystème libre et open source atteindre ce niveau
Certains des premiers MacBook Pro Retina n’ont qu’un réseau de 2 micros, mais la plupart disposent bien d’un réseau complet de 3 micros
Sinon, on retombe sur un mode de codec à très bas débit, très ancien, qui rend même l’audio entrant dans les écouteurs épouvantable
Donc, autant que possible, j’utilise toujours le micro du Mac
Même sur du matériel de PC portable bon marché — et bien sûr aussi sur du matériel haut de gamme comme un MBP — on peut obtenir des résultats étonnamment bons avec des techniques DSP logicielles.
J’aime le fait qu’une grande partie du travail audio d’Asahi soit applicable tel quel non seulement aux Mac, mais aussi aux PC portables classiques.
J’utilise déjà le plugin de synthèse d’harmoniques graves Bankstown et l’égaliseur à convolution développés pour Asahi sur un portable HP bon marché, et le résultat est étonnamment impressionnant.
Cela utilise aussi la fonctionnalité de chargement automatique de chaînes de plugins PipeWire développée pour Asahi.
Ce beamformer aussi semble avoir pas mal d’usages possibles en dehors de l’écosystème Asahi.
Concernant l’optimisation SIMD, les auteurs feraient bien de regarder faer.
La bibliothèque sous-jacente, pulp, n’a pas été une très bonne expérience pour moi personnellement, parce qu’elle essaie de faire des choses au-delà du champ de l’algèbre linéaire, mais si l’objectif est surtout d’accélérer des opérations d’algèbre linéaire, elle devrait bien convenir.
Je prépare un billet de blog et un podcast sur le SIMD en Rust, où j’aborderai ce sujet.
[1] : https://docs.rs/faer/latest/faer/
Dépôt GitHub : https://github.com/chadmed/triforce
En parlant du « réseau de microphones présent dans les ordinateurs portables Apple Silicon suivants », la liste inclut les 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 et MacBook Air 15" M2 ; je me demande si cela signifie que les M2/M3 n’ont pas de réseau de micros similaire, ou simplement qu’ils n’ont pas été testés.
Je me demande aussi si c’est pris en charge uniquement sous Linux.
Je ne sais pas vraiment si c’est possible sous macOS, ni si Apple fournit des flux dédiés pour chaque micro.
macOS effectue en interne des calculs de beamforming très similaires, et ne présente à l’utilisateur qu’un seul micro unifié.
M3 n’est pas encore pris en charge par Asahi Linux ; le fait qu’il ne soit pas dans la liste est donc indépendant de la question de savoir si le M3 possède ce type de micros.
macOS dispose, profondément dans le système, de son propre logiciel pour gérer cela, et ne l’expose aux applications que comme un micro ordinaire.
Le dernier rapport d’avancement d’Asahi Linux contient une discussion plus générale.
« Malheureusement, les microphones PDM sont très omnidirectionnels et très sensibles. Sans une forme ou une autre de beamforming, on ne s’en sort pas. »
https://asahilinux.org/2025/03/progress-report-6-14/
Il s’avère aussi qu’une partie du travail déjà effectué pour la sortie haut-parleur a été réutilisée pour l’entrée micro.
« Grâce aux bases que nous avions mises en place dans PipeWire et WirePlumber pour la prise en charge des haut-parleurs, connecter des chaînes DSP, dont Triforce, au micro a été vraiment simple. Il a suffi de mettre à jour les fichiers de configuration et de laisser WirePlumber faire le reste ! »
À propos de la phrase « comme avec les haut-parleurs, Apple essaie aussi d’en faire trop ici », ce serait vraiment intéressant que l’auteur de ce paquet donne son avis.
Je suis particulièrement curieux de savoir ce qu’il pense de l’implémentation des haut-parleurs.
Qu’est-ce qui est excessivement compliqué ? Le matériel, le logiciel ?
En tant qu’utilisateur de MBP et amateur d’audio, j’ai trouvé l’implémentation des haut-parleurs, surtout sur les grands modèles de MBP, vraiment impressionnante.
Cela dit, je ne suis qu’un amateur, et je n’en sais pas beaucoup plus que la présence de tweeters et d’une configuration à woofers opposés par paires.
Apple semble aussi utiliser des astuces comme l’égalisation adaptative employée par les concepteurs de « bonnes » enceintes Bluetooth pour tirer des performances correctes et une extension des graves de petits haut-parleurs.
L’un des problèmes est qu’il faut un DSP sophistiqué pour limiter la consommation électrique afin d’éviter la surchauffe.
Sans cela, le volume pouvant être atteint dans les limites de sécurité est très restreint.
Si vous voulez en savoir plus, le meilleur aperçu est probablement ici : https://github.com/AsahiLinux/asahi-audio
C’est vrai depuis plusieurs générations.
Quand j’utilisais un MBP de 2014, plusieurs amis étaient déjà surpris par le son en regardant des films en déplacement.
C’est pareil avec le MBP M4 : la qualité des haut-parleurs est, en pratique, au-delà de ce qui est réellement nécessaire.
De nos jours, au moins sur le matériel premium, l’« audio spatial » des haut-parleurs et les micros avec beamforming commencent à ressembler à des standards.
Un audio terne, bruyant, étriqué et déséquilibré ne passe plus.