Triforce - Apple SiliconノートPC向けビームフォーマー
(crates.io)- Triforceは、Apple SiliconノートPCのマイクアレイをmacOS以外でも活用するための、Rustベースの適応型ビームフォーマー
- 対応対象は M1/M2 MacBook Air・Pro 13"、M2 MacBook Air 15"、M1/M2 Pro・Max MacBook Pro 14"・16" に限定される
- これらの機種の三角形または直線のマイクアレイは、ビームフォーミングなしでは感度が高すぎて全方位的なため、目的の信号を分離しにくい
- 依存関係は、Cargo.lock に記載された crate 以外では LV2 のみが必要となるよう最小化を目指した構成
- 現在の実装は Apple の実装を上回るとは期待しにくく、SIMD/NEON 非対応のため広帯域分解とステレオ出力には対応していない
Apple Siliconマイクアレイ向けビームフォーマー
- Triforce は、Apple SiliconノートPCのマイクアレイ向けに Minimum Variance Distortionless Response 適応型ビームフォーマーを実装する
- 対応デバイスは以下の通り
- 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)
- 対象ノートPCのマイクアレイは三角形または直線の形で配置されている
- このアレイはビームフォーミングなしで使うと感度が高すぎて全方位的に動作し、有用性が低いため、macOS以外で活用するにはビームフォーマーが必要
- Cargo.lock に指定された crate 以外で追加に必要な依存関係は LV2
実装状況と既知の制限
- DSP と広帯域適応型ビームフォーミングに関するアクセス可能な文献を見つけるのが難しく、現在の実装は学部1年レベルの工学数学と複数のWebページ・PDFから得た原理をもとにした試み
- Apple の実装より性能が良いと期待するのは難しく、改善パッチは歓迎される
- 既知の制限は以下の通り
- nalgebra は明示的な SIMD 最適化を行わず、LLVM の自動ベクトル化に依存しているため、行列演算ルーチンの性能と効率が良くない
- SIMD/NEON 対応なしではリアルタイムオーディオプラグインには遅すぎるため、広帯域分解は行わない
- 出力はモノラルのみ対応で、疑似ステレオ出力のための追加行列処理は計算量が大きすぎる
- crates.io の統計では、総ダウンロード数は 4,247回、公開済みバージョンは 7個
1件のコメント
Hacker News のコメント
背景説明を含むブログ記事はこちら: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...
20年以上前に使っていた Toshiba Tablet PC コンバーチブルにはマイクのビームフォーミング配列があり、どこからの音を録音するか指定するソフトウェアも含まれていた
講義の録音が主な用途で、ノートPCの後ろ側にいる教授の方向へビームを向け、その方向の音だけを録音するよう設定できた
素晴らしいアイデアだったが、その後は見かけていない
これも優れたアイデアで、似た製品はいまでも出ている: https://electronics.sony.com/imaging/imaging-accessories/all...
会議室のマイク配列が誰が話しているかを把握し、その人の音声を分離する
大きな会議室でのビデオ会議では、昔から複数マイクのノイズが混ざらないよう、その時点で最も大きいマイクを選んで使っていたが、そこにビームフォーミングが入るとずっと良くなる
マイクが本体ではなく画面の平面上にあったなら、「正面」と「真後ろ」を区別できなかったのではないかと思う
自動運転車が茂みの向こうの歩行者を「見たり」、接近する緊急車両をより早く検知したり、自転車が見える前に音で聞き取ったりするなど、いろいろ良い用途があるかもしれない
いつもどう実装しているのか気になっていた
結局完成させられなかった修士論文が似たテーマだった
ほぼすべてのスマートフォンに少なくとも2つのマイクがあることを利用して、話者を 3次元で位置推定し、分離しようとしていた
得た教訓はこうだ: デバイス間のサンプリングレートはわずかにずれており、おおむね毎秒±1サンプル程度で大きくはないが考慮する必要がある
コンシューマー向けマイクのスペクトル特性はまちまちで、同じモデルの携帯電話を2台取り出しても、測定可能な差だけでなく聞いて分かる差まである
音は、とりわけコンクリート壁を含め、あらゆる場所で反射する
簡単にアクセスできるものの中では、車内が無響室に最も近い
ガウス関数のフーリエ変換はガウス関数なので、音声のような高調波信号の周波数を推定する際、波長が窓長の半分より少し短い場合に非常に有用だ
地面以外には反射するものがなく、実験対象の下にフォームを敷いていたかもしれない
もちろん環境ノイズはなくせないが、自分の機材から出る反射を減らすにはかなりうまくいったそうだ
Linux を Apple Silicon Mac で動かすには、一見些細に見える部分にもどれほど多くの作業が必要かを実感する
ここで「些細」というのは最大限の敬意を込めた表現だ。内蔵マイクはヘッドセットを忘れてこない限り、ほとんど使わないからだ
進捗報告（https://asahilinux.org/2025/03/progress-report-6-14/#is-this...）を引用すると、「それでも Apple だ。単純なものは何もない」
別体のアームが付いたラップアラウンド型マイク付きヘッドホンならもっと良いかもしれないが、日常的なヘッドホンはマイクの位置のせいで限界がある
MBP マイク は優れたノイズ除去まであり、たいていのヘッドセットのブームマイクより好んで使えるものだった
ガムを噛む音やコーヒーを飲む音のような不要な口元の音を拾いにくいという利点もある
会議に参加している人の99%は、普通のヘッドホンと MBP マイクの組み合わせを使っているように感じる
この構成の主な問題は、自分の声をヘッドホンで聞けないことだが、ノイズキャンセリングヘッドホンを使うと、ときどきかなり気になることがある
ただし Apple はしばらく前から、自分たちで整えた道からも外れつつある
核心は、Apple が作るものすべてが 垂直統合 されている点だ
AirDrop や Continuity のような機能を提供するには、スタック全体にまたがって実装する
DIY ルート、つまり Asahi が実質的に目指している方式を選ぶなら、足りないソフトウェアのピースも自分たちで作らなければならない
利点は、その作業の恩恵をエコシステム全体が受けられることだ。たとえば PipeWire の新しい DSP がそうだ
PC ハードウェアは概していまひとつで、こうした追加コンポーネントを除けば Apple ハードウェアも同じだ
しかし「パッケージ全体」はかなり高い基準を打ち立てており、自由なオープンソースエコシステムがその基準に到達する姿を見てみたい
初期の Retina MacBook Pro の一部は2マイク配列だけだが、大半は完全な3マイク配列を備えている
そうしないと非常に古い低ビットレートのコーデックモードに落ち、耳で聞く音声入力までひどくなる
だから可能な限り、いつも Mac のマイクを使っている
安価なノートPCハードウェアでも、もちろん MBP のような高級ハードウェアでも、ソフトウェアの DSP 手法で驚くほど良い結果が得られる
Asahi のオーディオ作業のかなりの部分が、Mac だけでなく一般的なノートPCにもそのまま適用できる点が気に入っている
すでに Asahi 向けに開発された Bankstown の低音高調波合成プラグインと畳み込みイコライザーを安価な HP ノートPCで使っているが、結果は驚くほど印象的だ
これも Asahi 向けに開発された PipeWire プラグインチェーンの自動ロード機能を利用している
この ビームフォーマーも Asahi エコシステムの外で使える場面がかなり多そうだ
SIMD 最適化に関しては、作者たちに faerを見てみてほしい
基盤ライブラリである pulp は、線形代数の範囲を超える処理をしようとしたため、個人的には体験があまり良くなかったが、目的が主に線形代数演算の高速化ならよく合いそうだ
Rust SIMD に関するブログ記事と関連ポッドキャストを準備中で、そこでこの内容を扱う予定だ
[1]: https://docs.rs/faer/latest/faer/
GitHub リポジトリ: https://github.com/chadmed/triforce
「次の Apple Silicon ノートPCに搭載されているマイク配列」として 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 を挙げているが、M2/M3 には似たマイク配列がないという意味なのか、それとも未テストという意味なのか気になる
これが Linux でしかサポートされないのかも気になる
macOS でも可能なのか、Apple がマイクごとの専用ストリームを提供しているのかはよく分からない
macOS は内部で非常によく似たビームフォーミング計算を行い、ユーザーには単一の統合マイクとしてだけ見せている
M3 は Asahi Linux がまだサポートしていないため、一覧にないことは M3 にこのようなマイクがあるかどうかとは別の問題だ
macOS にはシステムの深い部分でこれを処理する独自ソフトウェアがあり、アプリケーションには通常のマイクとしてだけ露出する
最新の Asahi Linux 進捗報告に、より一般的な議論がある
「残念ながら PDM マイクは非常に全指向性で、非常に感度が高い。何らかの形のビームフォーミングなしでは耐えられない」
https://asahilinux.org/2025/03/progress-report-6-14/
また、スピーカー出力のために以前行っていた作業の一部が、マイク入力にも再利用されたことが分かった
「スピーカー対応のために PipeWire と WirePlumber に敷いておいた基盤のおかげで、Triforce を含む DSP チェーンをマイクに接続するのは本当に簡単だった。設定ファイルを更新して、残りは WirePlumber に任せるだけでよかった！」
「スピーカーと同じく、Apple はここでも凝りすぎている」という文について、このパッケージの作者が意見を述べてくれたら本当に興味深い
特に スピーカー実装についてどう考えているのか気になる
何が過度に複雑なのか。ハードウェアなのか、ソフトウェアなのか？
MBP ユーザーで趣味でオーディオを扱う立場としては、特に大きい MBP モデルのスピーカー実装は本当に印象的だった
ただし私は趣味レベルで、ツイーターとデュアル・フォースキャンセリング・ウーファー構成以外は知らない
小さなスピーカーからまともな性能と低音の伸びを引き出すために、「良い」Bluetooth スピーカー設計者が使う適応型イコライザーのような工夫を、Apple も使っているように見える
問題の一つは、過熱を防ぐために電力使用を制限するには精巧な DSP が必要だという点だ
それがないと、安全限界内で出せる音量は非常に限られる
もっと知りたいなら、おそらくここが最も良い概要だ: https://github.com/AsahiLinux/asahi-audio
これは何世代にもわたって事実だった
2014年モデルの MBP を使っていたときも、移動中に映画を見ると友人たちが音に驚いていた
M4 MBP も同様で、スピーカー音質は実際には必要以上と言えるほどのレベルだ
最近は、少なくともプレミアムハードウェアでは、スピーカーの「空間オーディオ」とビームフォーミングマイクが標準のように感じられ始めている
こもっていて、うるさく、窮屈で、バランスの悪いオーディオは、もはや通用しない