Triforce - Beamformer für Apple-Silicon-Laptops

• Triforce ist ein Rust-basierter adaptiver Beamformer, um die Mikrofonanordnung von Apple-Silicon-Laptops auch außerhalb von macOS zu nutzen
• Unterstützt werden nur M1/M2 MacBook Air·Pro 13", M2 MacBook Air 15" sowie M1/M2 Pro·Max MacBook Pro 14"·16"
• Die dreieckigen oder linearen Mikrofonarrays dieser Geräte sind ohne Beamforming zu empfindlich und zu omnidirektional, sodass sich gewünschte Signale nur schwer trennen lassen
• Die Struktur ist darauf ausgelegt, die Abhängigkeiten zu minimieren, sodass zusätzlich zu den in Cargo.lock aufgeführten Crates nur LV2 benötigt wird
• Von der aktuellen Implementierung ist kaum zu erwarten, dass sie Apples Umsetzung übertrifft; zudem werden wegen fehlendem SIMD/NEON weder Breitbandzerlegung noch Stereo-Ausgabe unterstützt

---

Beamformer für Apple-Silicon-Mikrofonarrays

• Triforce implementiert einen adaptiven Minimum Variance Distortionless Response-Beamformer für die Mikrofonarrays von Apple-Silicon-Laptops
• Unterstützte Geräte sind:
  • 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)
• Die Mikrofonarrays der Ziel-Laptops sind in dreieckiger oder linearer Form angeordnet
• Ohne Beamforming sind diese Arrays zu empfindlich und arbeiten zu omnidirektional, was ihren praktischen Nutzen einschränkt; für den Einsatz außerhalb von macOS ist daher ein Beamformer nötig
• Zusätzlich zu den in Cargo.lock festgelegten Crates ist LV2 als weitere Abhängigkeit erforderlich

Implementierungsstand und bekannte Einschränkungen

• Da sich nur schwer zugängliche Literatur zu DSP und adaptivem Breitband-Beamforming finden ließ, basiert die aktuelle Implementierung auf einem Versuch mit ingenieurmathematischen Grundlagen auf Erstsemester-Niveau sowie Prinzipien aus diversen Webseiten und PDFs
• Es ist nicht zu erwarten, dass die Leistung besser ist als Apples Implementierung; Verbesserungspatches sind willkommen
• Bekannte Einschränkungen sind:
  • nalgebra verwendet keine explizite SIMD-Optimierung und verlässt sich auf die automatische Vektorisierung durch LLVM, weshalb Leistung und Effizienz der Matrixroutinen nicht besonders gut sind
  • Ohne SIMD/NEON-Unterstützung ist es für ein Echtzeit-Audio-Plugin zu langsam, daher wird keine Breitbandzerlegung durchgeführt
  • Die Ausgabe unterstützt nur Mono; zusätzliche Matrixverarbeitung für eine künstliche Stereo-Ausgabe wäre rechnerisch zu aufwendig
• Laut crates.io-Statistik gibt es insgesamt 4.247 Downloads und 7 veröffentlichte Versionen

[GN⁺]

Meinungen auf Hacker News

• Der Blogbeitrag mit Hintergrundinformationen ist hier: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...

• Ein Toshiba Tablet PC Convertible, das ich vor über 20 Jahren benutzt habe, hatte ein Mikrofonarray für Beamforming und enthielt auch Software, mit der man festlegen konnte, aus welcher Richtung Ton aufgenommen werden soll.
  Der Hauptanwendungsfall war das Aufzeichnen von Vorlesungen, und man konnte den Beam auf die Seite des Professors hinter dem Laptop richten, sodass nur der Ton von dort aufgenommen wurde.
  Eine erstaunliche Idee, aber danach habe ich so etwas nie wieder gesehen.

  • In der Blütezeit der Mini-Camcorder hatten einige Sony Handycam-Modelle ein „Zoom“-Mikrofon, das per Beamforming nur Ton aus einem Bereich sammelte, der ungefähr dem vom Sensor gesehenen Bildausschnitt entsprach.
    Auch das war eine großartige Idee, und ähnliche Produkte gibt es immer noch: https://electronics.sony.com/imaging/imaging-accessories/all...
  • In hochwertiger Videokonferenz-Hardware ist das weit verbreitet.
    Mikrofonarrays in Konferenzräumen erkennen, wer spricht, und isolieren dessen Audio.
    Videokonferenzen in großen Konferenzräumen haben schon lange jeweils das lauteste Mikrofon ausgewählt, um kein Rauschen von mehreren Mikrofonen zu vermischen; mit Beamforming wird das deutlich besser.
  • Ich frage mich, wie das funktioniert hat.
    Wenn die Mikrofone in der Bildschirmebene und nicht im Gehäuse saßen, hätten sie meiner Meinung nach „vorne“ und „direkt dahinter“ nicht unterscheiden können.
  • Eine Idee, über die ich seit Jahren nachdenke, die ich aber mangels Rechenressourcen nicht ausprobieren konnte: ein Diffusion Model trainieren, das ein Mikrofonarray und LIDAR als Ground-Truth-Daten nutzt und sich nur auf Basis der Signaltransformationen der Mikrofondaten „vorstellt“, wie die Welt aussieht.
    Es könnte viele gute Anwendungen geben: autonome Fahrzeuge, die Fußgänger „sehen“, die hinter Büschen verborgen sind, herannahende Einsatzfahrzeuge früher erkennen oder ein Fahrrad hören, bevor es sichtbar ist.
  • Seit dem Samsung S10 gibt es diese Funktion, wenn man Videos im Zoom-Modus aufnimmt.
    Ich habe mich immer gefragt, wie sie das umgesetzt haben.

• Meine nie fertiggestellte Masterarbeit behandelte ein ähnliches Thema.
  Ich wollte ausnutzen, dass fast jedes Smartphone mindestens zwei Mikrofone hat, um Sprecher dreidimensional zu lokalisieren und zu trennen.
  Das habe ich dabei gelernt: Die Abtastraten zwischen Geräten weichen leicht voneinander ab, ungefähr um ±1 Sample pro Sekunde; das ist nicht viel, muss aber berücksichtigt werden.
  Die spektralen Eigenschaften von Consumer-Mikrofonen sind sehr unterschiedlich; selbst zwei frisch ausgepackte Telefone desselben Modells weisen nicht nur messbare, sondern auch hörbare Unterschiede auf.
  Schall wird von allen möglichen Oberflächen reflektiert, besonders auch von Betonwänden.
  Unter den leicht zugänglichen Orten kommt das Innere eines Autos einem reflexionsarmen Raum am nächsten.
  Die Fourier-Transformation einer Gauß-Funktion ist wieder eine Gauß-Funktion; das ist beim Schätzen der Frequenz harmonischer Signale wie Sprache sehr nützlich, wenn die Wellenlänge etwas kürzer ist als die Hälfte der Fensterlänge.

  • Zu „das Innere eines Autos kommt unter den leicht zugänglichen Orten einem reflexionsarmen Raum am nächsten“: Ich erinnere mich, dass ein YouTuber das Problem des reflexionsarmen Raums löste, indem er ein großes leeres Feld suchte.
    Außer dem Boden gab es nichts, was reflektieren konnte, und möglicherweise legte er unter dem Experiment Schaumstoff aus.
    Natürlich beseitigt das keine Umgebungsgeräusche, aber offenbar funktionierte es ziemlich gut, um Reflexionen von der eigenen Ausrüstung zu reduzieren.
  • Wäre ein mit Teppich ausgelegter Kleiderschrank voller Kleidung nicht besser als ein Auto?
  • Den Teil mit der Gauß-Funktion verstehe ich, aber könntest du den Kernpunkt etwas ausführlicher erklären?

• Es wird einem bewusst, wie viel Arbeit selbst in scheinbar kleinen Details steckt, wenn Linux auf Apple Silicon Macs laufen soll.
  „Klein“ ist hier mit größtmöglichem Respekt gemeint. Das eingebaute Mikrofon nutzt man schließlich kaum, außer man hat sein Headset vergessen.
  Aus dem Fortschrittsbericht (https://asahilinux.org/2025/03/progress-report-6-14/#is-this...) zitiert: „Aber es ist Apple. Nichts ist einfach.“

  • Das eingebaute Mikrofon ist tatsächlich hervorragend; selbst wenn ich AirPods Pro trage, nutze ich oft das interne Mikrofon, weil die Audioqualität deutlich besser ist.
    Ein Wraparound-Mikrofon-Headset mit separatem Arm wäre vielleicht besser, aber Alltagskopfhörer sind wegen der Mikrofonposition begrenzt.
  • Das entspricht überhaupt nicht meiner Erfahrung.
    Das MBP-Mikrofon war mit seiner guten Geräuschunterdrückung den meisten Headset-Boom-Mikrofonen vorzuziehen.
    Es hat außerdem den Vorteil, unnötige Geräusche in Mundnähe wie Kaugummikauen oder Kaffeetrinken weniger stark aufzunehmen.
    Gefühlt verwenden 99 % der Leute in Meetings normale Kopfhörer plus MBP-Mikrofon.
    Das Hauptproblem dieser Konfiguration ist, dass man die eigene Stimme nicht im Kopfhörer hört, was mit Noise-Cancelling-Kopfhörern manchmal ziemlich störend sein kann.
  • Wenn man das gesamte Paket so nutzt, wie es als Produkt ausgeliefert wird, ist es tatsächlich einfach.
    Allerdings weicht Apple seit einiger Zeit sogar von den Wegen ab, die es selbst geebnet hat.
    Der Kern ist, dass alles, was Apple baut, vertikal integriert ist.
    Um Funktionen wie AirDrop oder Continuity bereitzustellen, implementieren sie sie quer durch den gesamten Stack.
    Wenn man den DIY-Weg wählt, also im Grunde den Weg, den Asahi verfolgt, muss man die fehlenden Softwareteile ebenfalls selbst bauen.
    Der Vorteil ist, dass diese Arbeit dem gesamten Ökosystem zugutekommt. Ein Beispiel ist der neue DSP in PipeWire.
    PC-Hardware ist im Allgemeinen eher schlecht, und ohne solche zusätzlichen Komponenten gilt das auch für Apple-Hardware.
    Aber das „Gesamtpaket“ hat die Messlatte ziemlich hoch gelegt, und ich möchte sehen, wie das freie Open-Source-Ökosystem dieses Niveau erreicht.
  • Ein 3-Mikrofon-Array gibt es auch in Intel-basierten Retina MacBooks, daher könnte diese Arbeit auch für eine ordentliche Audiounterstützung dieser älteren Hardware nützlich sein.
    Einige frühe Retina MacBook Pro haben nur ein 2-Mikrofon-Array, die meisten besitzen aber das vollständige 3-Mikrofon-Array.
  • Da die meisten Mikrofone noch Bluetooth 5.0 verwenden, nutze ich auch mit Headset das Mac-Mikrofon.
    Sonst fällt es in einen uralten Codec-Modus mit sehr niedriger Bitrate zurück, wodurch sogar das Audiosignal, das man hört, furchtbar wird.
    Deshalb verwende ich nach Möglichkeit immer das Mac-Mikrofon.

• Auch auf günstiger Notebook-Hardware – und natürlich ebenso auf hochwertiger Hardware wie einem MBP – lassen sich mit softwarebasierten DSP-Verfahren erstaunlich gute Ergebnisse erzielen.
  Mir gefällt, dass ein großer Teil der Audioarbeit von Asahi nicht nur für Macs, sondern auch für gewöhnliche Notebooks direkt anwendbar ist.
  Ich nutze das bereits für Asahi entwickelte Bankstown-Plug-in zur Bass-Obertönesynthese und den Convolution Equalizer auf einem günstigen HP-Notebook, und die Ergebnisse sind erstaunlich beeindruckend.
  Auch das nutzt die für Asahi entwickelte Funktion zum automatischen Laden von PipeWire-Plug-in-Chains.
  Für diesen Beamformer dürfte es außerhalb des Asahi-Ökosystems ebenfalls ziemlich viele Einsatzmöglichkeiten geben.

• Im Zusammenhang mit SIMD-Optimierung wäre es gut, wenn sich die Autoren faer ansehen würden.
  Mit der zugrunde liegenden Bibliothek pulp habe ich persönlich keine besonders guten Erfahrungen gemacht, weil sie Aufgaben über den Bereich der linearen Algebra hinaus abdecken will. Wenn das Ziel aber hauptsächlich die Beschleunigung linear-algebraischer Operationen ist, dürfte sie gut passen.
  Ich bereite gerade einen Blogbeitrag zu Rust SIMD und einen zugehörigen Podcast vor und werde das dort behandeln.
  [1]: https://docs.rs/faer/latest/faer/

• GitHub-Repository: https://github.com/chadmed/triforce

• Es werden „die Mikrofon-Arrays in den folgenden Apple-Silicon-Notebooks“ erwähnt und dann 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 sowie MacBook Air 15" M2 aufgelistet. Ich frage mich, ob das bedeutet, dass es bei M2/M3 keine ähnlichen Mikrofon-Arrays gibt, oder ob sie nur nicht getestet wurden.
  Außerdem frage ich mich, ob das nur unter Linux unterstützt wird.
  Ich weiß nicht genau, ob das auch unter macOS möglich ist und ob Apple für jedes Mikrofon einen eigenen dedizierten Stream bereitstellt.

  • Das wurde für Asahi Linux gemacht.
    macOS führt intern sehr ähnliche Beamforming-Berechnungen durch und zeigt den Nutzern nur ein einziges zusammengefasstes Mikrofon an.
  • In der Liste sind M2-Geräte enthalten.
    M3 wird von Asahi Linux noch nicht unterstützt; dass M3 nicht in der Liste steht, sagt also nichts darüber aus, ob M3 solche Mikrofone hat.
    macOS hat dafür eigene Software tief im System und exponiert Anwendungen nur ein normales Mikrofon.
  • Asahi Linux unterstützt M3- und M4-Prozessoren noch nicht.

• Im neuesten Fortschrittsbericht zu Asahi Linux gibt es eine allgemeinere Diskussion dazu.
  „Leider sind PDM-Mikrofone sehr omnidirektional und sehr empfindlich. Ohne irgendeine Form von Beamforming kommt man damit nicht aus.“
  https://asahilinux.org/2025/03/progress-report-6-14/
  Außerdem stellte sich heraus, dass ein Teil der früher für die Lautsprecherausgabe geleisteten Arbeit auch für den Mikrofoneingang wiederverwendet wurde.
  „Dank der Grundlage, die wir für die Lautsprecherunterstützung in PipeWire und WirePlumber gelegt hatten, war es wirklich einfach, DSP-Chains einschließlich Triforce mit den Mikrofonen zu verbinden. Es reichte, die Konfigurationsdateien zu aktualisieren und den Rest WirePlumber erledigen zu lassen!“

• Zu dem Satz „Wie bei den Lautsprechern versucht Apple auch hier, zu sehr aufzutrumpfen“ wäre es wirklich interessant, wenn sich der Autor dieses Pakets dazu äußern würde.
  Besonders interessiert mich, was er von der Lautsprecherimplementierung hält.
  Was ist übermäßig kompliziert – die Hardware oder die Software?
  Als MBP-Nutzer und Audio-Hobbyist fand ich die Lautsprecherimplementierung besonders bei den größeren MBP-Modellen wirklich beeindruckend.
  Allerdings bin ich nur Hobbyist und weiß außer über Tweeter und die doppelt gegenläufige Woofer-Konfiguration nicht viel.
  Es wirkt so, als würde Apple ähnliche Tricks wie adaptive Equalizer einsetzen, wie sie Entwickler „guter“ Bluetooth-Lautsprecher nutzen, um aus kleinen Lautsprechern ordentliche Leistung und Bass-Erweiterung herauszuholen.

  • Eine brauchbare Lautsprecherunterstützung in Asahi Linux hinzubekommen, war eine große Sache.
    Eines der Probleme ist, dass ausgefeilte DSP nötig ist, um die Leistungsaufnahme zu begrenzen und Überhitzung zu verhindern.
    Ohne das ist die Lautstärke, die innerhalb sicherer Grenzen möglich ist, stark eingeschränkt.
    Wenn du mehr wissen willst, ist das hier wahrscheinlich der beste Überblick: https://github.com/AsahiLinux/asahi-audio
  • Mit „Wie bei den Lautsprechern übertreibt es Apple hier“ ist wohl gemeint, dass die Lautsprecher in Apple-Notebooks der Konkurrenz weit voraus sind.
    Das gilt seit mehreren Generationen.
    Schon als ich ein MBP von 2014 genutzt habe, waren mehrere Freunde beim Filmeschauen unterwegs vom Klang überrascht.
    Beim M4 MBP ist es genauso: Die Lautsprecherqualität liegt tatsächlich auf einem Niveau, das eigentlich mehr ist, als nötig wäre.
  • Ohne Wertung vermute ich, dass damit gemeint ist, dass es ohne solche Software nicht richtig funktioniert.
  • Dieses Paket scheint für Leute gedacht zu sein, die auf einem Notebook eine Linux-Distribution nutzen und dabei dieselben Funktionen wie unter nativem macOS haben möchten.
  • Ich bin auch verwirrt.
    Heutzutage fühlen sich „Spatial Audio“ bei Lautsprechern und Beamforming-Mikrofone zumindest bei Premium-Hardware zunehmend wie ein Standard an.
    Dumpfes, lautes, beengtes und unausgewogenes Audio zieht heute nicht mehr.