フェーズドアレイマイクロフォン（2023）
(benwang.dev)- 192チャンネルの フェーズドアレイマイクロフォン は、録音後でも指向性を変更したり、数十万地点に同時に焦点を合わせたりできるため、一般的な指向性マイクでは難しい音源位置推定と可視化を可能にする
- ハードウェアは放射状のマイクアームと中央ハブで構成され、約 $700 のコストで、192個のMEMSマイク、Colorlight i5 FPGAカード、Gigabit Ethernet転送構成を使用する
- FPGAは複雑な前処理よりも 生のPDMデータ転送 に集中し、3.125MHz入力を処理しつつ、約715MbpsでGigabit Ethernet帯域の約70%を使用する
- ソフトウェアはCICフィルタ、FFTベースの補正、GPU最適化、Tritonビームフォーミングを組み合わせ、3D近距離および2D遠距離の音源位置を リアルタイム可視化 する
- UDPパケットは
tcpdumpでキャプチャして再生できるが、生データ保存は 87.5MB/s に達し、1時間の録音に315GBが必要となる
192チャンネル フェーズドアレイマイクロフォン構成
- 192チャンネル フェーズドアレイマイクロフォン に、FPGAデータ収集とGPUベースのビームフォーミング・可視化を組み合わせている
- 一般的な指向性マイクと異なり、フェーズドアレイは録音後でも指向性を変更でき、リアルタイムで数十万の地点に同時に焦点を合わせられる
- すべての設計は オープンソース として公開されている
ハードウェア設計
-
アレイ構造とコスト
- 多数のマイクを広い間隔分布で配置してフェーズドアレイを構成する
- 線形アレイでは、広帯域信号に対してマイク間の 指数間隔 が最適であることが知られている
- 2Dアレイでは、対称な線形アレイアームを放射状に配置し、中央ハブボードを小さく保っている
- アレイ全体のコストは約 $700
-
アームボード
- 各アームの長さはPCB製造・実装の限界に合わせており、JLCPCBの4層PCB製造・実装の最大長は 570mm だった
- マイクには1個あたり約 $0.5 の低価格なデジタル出力MEMSマイクを使用する
- この価格帯ではマイク間の性能差は大きくない
- 多くは10kHzまでは十分な性能を示すが、位相遅延と音量マッチングは明示されていない
- マイクは PDM(pulse density modulation) 方式でデータを出力する
- 可聴域よりはるかに高い最大4MHz周波数で1ビット出力を行う
- 高いサンプリング速度で量子化ノイズを補う
- クロックの立ち上がり・立ち下がりエッジでデータをラッチするDDRに対応し、2つのマイクを1本の線に多重化できる
- 各アームは8個のマイクと4本の出力ラインを持ち、クロック入力ラインには出力バッファを配置する
- 数百個のマイクが同じクロック信号を共有しても立ち上がり時間が妥当な水準に保たれるよう設計されている
- アームPCBの歩留まりは良くなく、初期状態で動作したボードは約 50% だった
- 最も一般的な故障は、クロックラインが3V3またはGNDに短絡する問題だった
- 短絡の解消には、マイクを1つずつ取り外す試行錯誤が必要だった
- 一部のマイクはリワーク後も誤ったデータを出力し、コード側でそのマイクを マスキング して除外した
- 次の設計では、クロックライン直列抵抗、パネル化改善、ソルダーペーストステンシル改善によりリワークを減らせる
-
ハブボード
- データ収集には、多数の低遅延I/OとGigabit Ethernetのような高速インターフェースを必要とする FPGA を使用する
- 具体的には Colorlight i5 カードを選択した
- 十分なI/O、低価格、入手しやすさ、統合Ethernet PHY 2基が理由である
- このプロジェクトではEthernet PHYは1基のみ使用する
- このカードは元々LEDパネル用のEthernetインターフェースだが、完全にリバースエンジニアリング されている
- 約100本のGPIOがDDR2コネクタで露出しており、元のFPGAのBGAよりファンアウトしやすい
- ハブにはFPGAのほか、簡単な電源管理回路、アームボード用コネクタ、統合マグネティクス付きEthernetコネクタが含まれる
-
機構設計
- アームはPCB取り付け用スタンドオフ・ナットとM3ネジでハブに取り付ける
- アームとハブの接続は 8ピン 2mmピッチコネクタ で行う
- 初期設計では、アームPCBのスロットと円周方向の構造PCBをかみ合わせたが、アームのねじり剛性が低く、構造全体が容易に変形した
- 最終設計では、アレイ外周にレーザーカットした 1/4インチ MDF の部材を置き、各アームをケーブルタイでMDFに固定した
- マイクアレイは壁に設置され反射の影響を受けやすいため、補正を容易にする目的で 吸音フォーム により反射を減らしている
FPGAゲートウェア
-
設計目標
- ゲートウェアの中核目標は、収集した生データを損失なく安定してコンピュータへ転送すること
- FPGA上でデシメーションやフィルタリングを行えばデータレートは下げられるが、生の PDMデータ もGigabit Ethernetで転送可能である
- 生データを送ることでFPGAコードの複雑さが減り、反復開発が速くなる
- コードのコンパイルは配置・配線より速く、通常コードでデバッガを使うほうがゲートウェアデバッグより容易である
-
PDMインターフェース
- PDM入力モジュールは50MHzシステムクロックを16分周して 3.125MHz PDMクロック を出力する
- 各クロックエッジの後に96本の入力ピンをラッチし、各クロックサイクルごとに32ビットデータをシフトする
- 192ビットのデータチャンクごとに32ビット増加整数ヘッダを付与する
- PDMインターフェースの入力データレートは 3.125MHz × 96入力ピン × DDR 2 = 600Mbps
- ヘッダ込みの出力データレートは 700Mbps で、32ビット出力データパス使用率は約40%
-
パケット化とUDP転送
- パケット化モジュールは、特殊な入力インターフェースを持つFIFOバッファに近い
- EthernetインターフェースがPDM出力より高速なため、標準FIFOのように項目が1つあるだけで出力すると要求サイズより小さいパケットが生成されうる
- パケット化モジュールは、1パケット分のデータがキューにたまるまで待ってから送信を開始し、固定サイズパケット を保証する
- 各パケットには224ビットのPDM出力ブロックが48個入る
- 1ブロックは192ビットのデータと32ビットのヘッダで構成される
- パケットあたりデータ量は1344バイト
- これにIPv4ヘッダ20バイトとUDPヘッダ8バイトが加わる
- パケットレートは約 65kpps で、結果として線速度は 715Mbps、Gigabit Ethernet使用率は約70%
- UDPストリーミングにはLiteEthを使用する
- UDP/IPカプセル化、ARPテーブルのような低レベルの複雑さを抽象化する
- FIFOをUDPストリームへ簡単に接続できるインターフェースを提供する
- 断続的な遅延はパケット化FIFOのバッファ余裕で吸収される
-
FPGAリソース使用量
- Colorlight i5のFPGAは
LFE5U-25F-6BG381Cで、25k LUT を持つ - 設計はオープンソースのProject Trellisツールチェーンで配置・配線した
- ゲートウェアを単純に保っているためリソース使用率は低く、追加機能を入れる余地が大きい
- DP16KD: 16/56, 28%
- TRELLIS_FF: 1950/24288, 8%
- TRELLIS_COMB: 3701/24288, 15%
- 最大クロックは50MHz目標に対し73.17MHzで通過した
- Ethernet RXクロックのタイミング警告は、LiteEthのgray counterに関する false positive である
- Colorlight i5のFPGAは
ソフトウェア処理パイプライン
-
CICフィルタ
- 各マイクは 3.125MHz 1ビット信号 を出力し、後続処理のためにより低いサンプリングレートとビット深度へ落とす必要がある
- この処理には算術演算の少ないCICフィルタを使用する
- Tom Verbeureの Moving Average and CIC Filters シリーズを参考にしている
- 最終選択は 4段、16倍デシメーションCICフィルタ
- サンプリングレートを195kHzへ下げる
- 出力は32ビット
- 3.125MHzデータを受け取るには、サンプルの束1つを 320ns 以内に処理する必要がある
- 単純なRust実装は単一コアでは十分に速くなく、抽象化を減らして自動ベクトル化を促しやすい実装を最終的に採用した
- SIMD intrinsic実装ははるかに高速だったが、他のコードと併用するとアラインメント問題に遭遇した
- ベンチマーク結果:
bench_cic: 574ns/iter, 41MB/sbench_fast_cic: 181ns/iter, 132MB/sbench_simd_cic: 36ns/iter, 666MB/s
-
補正
- アレイ補正は、ホワイトノイズを再生するスピーカーをアレイ前方の部屋内で動かしながら実施する
- すべてのマイクペア間でFFTベースの 相互相関 を計算し、相対遅延を求める
- マイクペアは18,000組を超えるため計算量が大きい
- 16k〜64kのウィンドウサイズではFFTがメモリボトルネックになるため、IFFTとピーク探索を組み合わせて結果をメモリに書き出さないようにし、15倍の高速化 を得た
- Ryzen 7950Xではこの処理はリアルタイムで動作する
- その後、各時点の音源位置と各マイク位置を勾配降下法で最適化する
- 損失関数は、測定された相関と理想的な相関の差を小さくする
- マイク位置が初期位置から過度にずれないようにする
- 音源軌跡のjerkも抑える
- 補正過程では音速も最適化パラメータに含まれ、全体手順は過度に複雑な 温度計 のように機能する
- 数百回の反復後、音源位置、マイク位置、音速のような定数が妥当な解へ収束する
- この問題はGPUベクトル化と相性が良く、数秒で収束する
- 最終的な平均位置誤差は約 1mm レベル
- 構造剛性不足によるたわみのような大規模な系統的歪みも補正する
- 設計位置と補正後位置の最大誤差は約5mm
- 10kHz音の波長は約3.4cmのため、補正しないと高周波で有意な位相誤差が生じうる
ビームフォーミングと可視化
-
ビームフォーミング方式
- ビームフォーミングは生のマイク入力を処理して 指向性応答 を作る過程である
- 実装した方式は最も単純なdelay-and-sum、すなわちDASである
- 各信号を音源までの距離差に応じて遅延させて加算する
- このプロジェクトでは周波数領域でビームフォーミングを行う
- 周波数領域では、遅延は必要な遅延に比例する線形位相項と信号の複素乗算として実装される
- サンプリング周期の整数倍でない遅延も自然に扱える
- 元のアレイの複数の重なり合うサブアレイを周波数帯ごとに使い分ける
- 全周波数で全マイクを使ってビームフォーミングする必要がなく、処理量を減らし、全周波数でのビームフォーミング利得を揃えるのにも役立つ
-
TritonベースのGPU実装
-
近距離3Dビームフォーミング
- 近距離3Dビームフォーミングは 5cmボクセルグリッド で実行する
- グリッドサイズは64×64×64
- RTX 4090で 12Hz の更新速度を達成した
- これ以上の高速化は、小さな作業単位におけるCPU-GPU同期の非最適なオーバーヘッドに制限される
- ボクセルグリッドはOpenGLベースの高性能可視化ライブラリ VisPy で可視化する
- 25万個の半透明ボクセル描画は、現代のゲームのポリゴン数と比べればインタラクティブなフレームレートで問題にならない
-
遠距離2Dビームフォーミング
- 遠距離音源では波面がほぼ平面なので、音源がどれだけ遠いかはアレイ信号を有意には変えない
- 近距離音源では波面の曲率が大きく、3D位置 を決定できる
- 遠距離ビームフォーミングは深度次元がないため、より高い解像度で実行できる
- 512×512ピクセルグリッドを使用し、同様に12Hzの更新速度を達成した
- 遠距離ビームフォーミングは、真の平面波仮定の代わりに、点を遠方に配置する近似を用いる
- 室内反射やマルチパスが多いため、2D可視化デモは音響環境の影響を受ける
-
指向性オーディオ
- 前述の2つのビームフォーミング実装は各位置の音エネルギーを計算するが、ビームフォーミング済みオーディオ自体をメモリ上に生成するわけではない
- 指向性オーディオ録音のため、時間領域delay-and-sumビームフォーマを実装した
- アレイ中心基準の3D座標を入力として受け取る
- オーディオサンプルを出力する
- このビームフォーマは出力に対して位置が 微分可能 である
- オーディオソース位置を微分可能な損失関数で最適化できる
- 複数話者の文字起こしに強制アラインメントモデルを使い、各話者の物理位置を求める応用が可能かもしれない
- 1台のスピーカーはアレイ前方で音声を再生し、別のスピーカーはアレイ中心から約45度離れた同距離でホワイトノイズを再生する方法で効果を比較した
- 単一マイクの生オーディオとビームフォーミング後オーディオを比較し、ビームフォーミング効果を示している
録音方法と限界
- マイクアレイのデータはUDPパケットなので、
tcpdumpのようなツールで録音できる - パケットキャプチャファイルを読み込み、リスナーへパケットを再注入できる
- 先述のプログラム群はリアルタイム動作向けに設計されているが、この方法により録音データでも動作する
- 欠点は、生データをそのまま保存するため出力データレートが非常に高いこと
- 量子化ノイズまで忠実に保存する
- データレートは 87.5MB/s
- 1時間の録音には 315GB が必要
- より最適化された実装では、圧縮を適用したり、CICフィルタ後の低いサンプリングレートで録音したりできる
可能な拡張
- プロジェクトは事実上完成しており、近い将来に追加作業を行う予定はない
- それでも自作したい人向けには拡張の余地が残っている
- DAMAS のような、より高度なビームフォーミングアルゴリズムを使う
- 音がどこから出ているかを見て、その位置からオーディオを録音するなど、既存機能を組み合わせたより良いGUI
- 微分可能ビームフォーミングとニューラルネットワークモデルの結合。たとえば強制アラインメントの例のような応用も可能
1件のコメント
Hacker Newsのコメント
較正の過程では、音速もシステムの最適モデルを得るために最適化されるパラメータなので、全体の手順がばかばかしいほど過剰設計された温度計のように振る舞うのが面白い
電子工学の格言「すべてのセンサーは温度センサーであり、一部はそれ以外のものも測定する」を思い出す
調べてみると、その方法で温度も測定でき、グラフを外挿すれば絶対零度も求められた
記憶では結果は約20Kずれていたが、高校生のガレージプロジェクトとしてはかなり良かったと思う
十分に高精度な慣性計測装置(IMU)なら、コリオリ効果を利用して比較的正確な経度測定まで可能だという例が特に気に入っている
https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN
以前、大きなY字型に床へ配置した4本のマイクアレイでコウモリの多辺測量をするプロジェクトをやった
4本のマイクに到達した時間差を使って、アレイの上を飛んだ各コウモリの位置を特定し、種まで識別できた
風力タービン設置が環境に与える影響を判断する研究に使われていて、かなり面白かった
短いレーザーパルスで蚊を追跡して殺すために開発された装置だった
蚊の空間位置を高精度に捉える必要があったため、副次的に羽ばたき周波数の違いを検出して、性別や種によって標的を識別できた
もちろんハードウェアもソフトウェアも力不足で、TDOAアルゴリズムも最も素朴な形で実装し、相互相関で時間差を推定する方法も非常に非効率だった
それでも多くを学べたし、最終的にはSARシステムの博士課程へとつながった
SARは実際にはアレイではなく、プラットフォームの移動を使うビームフォーマに近いと思う
コウモリの肺は非常に敏感で、大型タービンの圧力差を横切って飛ぶと毛細血管が事実上破裂する、という話を聞いたことがある
どこから始めるのが良いか、参考になる資料があればうれしい
サソリの下にマイクアレイを置き、コウモリがサソリをスキャンしようとして超音波ビームをどう動かすかを示していた
本当に驚くべき結果だった [0]
[0]: https://www.youtube.com/watch?v=57ScSPWhGqU
なぜアレイにTDM I2Sマイクを使わず、PDMを使ったのか気になる
ICS-52000は比較的安価で100個単位なら2ドル程度、4マイクのブレークアウトボードもあり、8個や16個までチェーン接続できると理解している
https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
JetsonやI2S対応のDSP/GPU搭載ハードウェアを使えば、I2Sポートごとに16個のマイクをチェーン接続できるので、FPGA構成より組み立てもプログラミングもずっと簡単そうだ
マイクが192個になると、1個2ドルと0.5ドルの差はかなり大きい
16個のデイジーチェーンにしても、十分な数のI2Sインターフェースを持つデバイスを見つけるのは難しく、たいていのデバイスは必要な数を備えていない
FPGAとカスタムハードウェアそのものも楽しさの一部だった
漏れたガスのシューという音や電気アークのコロナ放電を聞くには、より高い周波数が有用だ
Orinは内部的にはI2Sポートが6つあるので、16*6 = 96本のマイクまではいけそうで、かなり良い数字だ
ただ実際には3つしかボード外に出ておらず、しかも別々の開発ボードコネクタにあるようだ [1]
設計では常に細部が問題になるので、96本より多く必要ならFPGAのほうが構成しやすいかもしれない
メモしていた部品は、ICS-52000 $3.50 20kHz、ICS-41350 $1.05 40kHz、SPH0641LU4H-1 $1.45 80kHz+ だった
[1] https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide...
I2Sが最善でない理由は2つほどある
I2SはPDMの2ピンに対して3ピン必要だ
ただし、提示されているデータシートのようにマイクをデイジーチェーンできるならかなり魅力的で、標準的なI2Sではなくてもこの論点は消える
PDMははるかに高いサンプリングレートを扱えるため、遅延和演算でどの遅延を選ぶかの柔軟性が増す
例えばPDMクロックが2MHzなら、理論上は0.5µs精度で遅延させられる
実際にはもっと低い精度にするだろうが、I2Sクロックは通常せいぜい192kHz程度だ
PDMマイクのほうが安価でもある
YouTubeで音響カメラを検索すると、性能を示すかなり印象的なデモが見つかる。
しばらく注目している企業のひとつがここで、FLIRのような大手企業も参入してきているようだ: https://www.youtube.com/@gfaitechgmbh
興味深いが不気味な利用例として、公共の場を録音しておいて、後から特定の個人同士の会話に「ズームイン」することが挙げられる。
人工内耳を使っている友人と話したところ、適切な信号処理が組み合わされれば、聞き取りに大いに役立つ可能性があるように思える。
大学院生に戻って、超音波スピーカーアレイと組み合わせた医療応用を試してみたい。
本質的にはリアルタイムフィードバック付きの超強力なHIFU（高強度集束超音波）のようなものだ。
https://en.wikipedia.org/wiki/Focused_ultrasound
周波数がずっと高く、40kHzではなく1〜10MHz程度を考える必要があり、一般的な電子回路は事実上使えない。
話してみたければ、プロフィールのメールに連絡してほしい。
こうした技術がうまく製品化されて、さまざまなモバイル機器に搭載されるといいと思う。
アシスタントや汎用翻訳機のようなものが伸び悩む理由のひとつは、音声品質の悪さにあると思う。
ノイズを減らし、方向を検出できれば大きな助けになる可能性がある。
たとえば、食卓を囲んだグループ会話をリアルタイム翻訳したい。
まずはスマートフォンとヘッドホンがそれぞれのマイクを組み合わせて、この用途に使えるようになるといい。
さらに、近くにあるすべてのスマートフォンが協調して高品質な指向性オーディオを提供できたらどうだろう。
もちろん、プライバシーの問題を解決できることが前提だ。
人生を変え得る。
AndroidのLive Transcribeは今でも非常に優れているが、どの単語がどの話者から発せられたかを分離しようとはしていない。
騒がしい部屋の中でも、誰かが自分たちに話している内容を理解できるように、脳が膨大な処理を行っていることがわかる。
https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
おおよそ取得したい最高音響周波数の10倍レベル、つまり数万分の1秒以内である必要がある。
また、アレイマイクの配置が直線や円などの単純な幾何形状でない場合、改善された信号を取り出すコード、つまり数学は非常に難しくなる。
Boeingはこの種の装置の球形版を作り、787試作機で防音材候補を見つけるのに使っていた。
航空機のように騒がしい環境では、聴覚の錯覚によって音が実際とは別の場所から来ているように感じられることがあるという。
防音材に重量の予算制約があるなら、80/20のポイントを正しく押さえられるかが重要になる。
Zynq 7010で遊んでみたいなら、EBAZ4205ボードを見てみる価値がある。
AliExpressで20〜30ユーロで買えて、もともとはBitcoinマイニングコントローラだった。
一部の人たちが全体をリバースエンジニアリングしてGitHubに公開しており、GPIOにアクセスするためのアダプタ基板もある。
もっと複雑さの少ないところから始めたいなら、GoWin FPGAを使う「Sipeed」ボードのような中国製FPGAもある。
かなり実用的で、IDEも無料だ。
昨夜調べていたら、まさにこのページにたどり着いた。
部屋にマイクを設置して、特定の領域の音声だけを録音する方法を知っている人がいないか気になっている。
私の用途では、ソファ側を録音して、オンラインの友人たちと一緒にテレビを見ながら、友人たちの声と放送ノイズを音声から取り除きたい。
マイクアレイを作ってビームステアリングを使えば可能そうに思えるが、リアルタイムで動作するコード例はGitHubでもあまり見つけられなかった。
https://obsproject.com/
https://voicemeeter.com/
必要なのはマイクやビームフォーミング技術ではなく、あらゆるビデオ会議ソフトウェアが使っているのと同じエコーキャンセルだ。
放送音声と友人の音声を入力として与え、それぞれにエコーキャンセルを適用すればよい。
1点、つまりソファから各マイクまでの距離を測り、音がソファからマイクまで移動する時間分だけ時間領域で信号を遅延させてから足し合わせればよい。
基本的には、距離が異なっていてもマイクがソファからの信号を同じ時刻に受け取ったかのように揃えようとするものだ。
この方式を有効に機能させるには、マイク間の距離差が十分にある必要がある。