NAM A2-LiteをiRig HD Xに組み込む

iRig HD XにNAM A2-Liteを組み込む

iRig HD Xは、ギターオーディオを処理のために別のコンピューターに送信するために使用されていました。今では、アンプモデリングを自身で行います。

ギター → iRigコーデック → NAM A2-Lite → ヘッドフォンまたはアンプ

このモデルは、インターフェースに既に内蔵されている500MHzマイクロコントローラーで動作します。USBが電源を供給します。ホイールは引き続きヘッドフォン音量を制御します。出力されるサウンドは、iRig内でリアルタイムにレンダリングされた、OD808を前にした5150のキャプチャです。

［画像: ギターの横に置かれたiRig HD X］

*IK Multimediaの公式iRig HD X画像ギャラリーより写真。

インターフェースの中にコンピューターがあった

これは、HD XのUSBオーディオパスを書き換えた直後に始まりました。その作業により、インターフェースは私のペダルプロトタイプ内のESP32-S3で使用可能になりました。ファームウェアの読み出しが可能になり、デバイスがオーディオをどのように移動させるかを理解した後、基板上のより大きなチップが無視できなくなりました。

HD XはNXP MIMXRT1011DAE5Aを中心に構築されています。これは、ハードウェア浮動小数点演算、密結合メモリ、外部QSPIフラッシュ、SAIオーディオ、およびeDMAを備えた500MHz Cortex-M7です。その通常の役割は、コーデックの設定、サンプルの移動、およびコントロールの処理です。プロセッサの大部分は、オーディオ割り込みの間に待機していました。

NAM A2-Liteは、まさにこの種のマシン向けに設計されました。これは、Taurusで使用しているA2ファミリーのコンパクトなメンバーであり、1つの繰り返しアンプモデルと48kHzオーディオを備えています。私はオンラインで見つけたjp_is_out_of_tuneによる、OD808を前にした5150のキャプチャを使用しました。これは、組み込みテスト全体で使用していたのと同じモデルです。

私は、インターフェース内にパス全体を収めたかったのです。コーデックがギターをキャプチャし、RT1011がモデルを実行し、コーデックが結果を再生します。ESP32-S3、Mac、および電話はすべてオーディオパスから消えることができます。

エンジンを128 KiBに収める

プロセッサには、4つの32 KiB FlexRAMバンクがあります。これらのバンクは、起動時に命令TCM、データTCM、または通常のオンチップRAMにすることができます。A2-Liteのエンジンオブジェクトは91,204バイトを消費するため、通常のメモリレイアウトは使用できませんでした。

3つのバンクをDTCMに、1つをOCRAMに設定しました。

コンパクトモデルは7,516バイトです。起動まではフラッシュに留まり、その後、重みと履歴がDTCMにロードされます。最終的なライブビルドは91,232バイトのDTCMを使用し、7,072バイトの空き容量を残します。予約されたスタックを含むOCRAMの使用量は10,664バイトです。これにより、オーディオ処理機構やファームウェアが生存するために必要なその他のものに22,104バイトが残ります。

48フレームから16フレームへ

エンジンを48サンプルブロックで起動しました。48kHzでは、各ブロックは1ミリ秒持続し、500MHzプロセッサに500,000サイクルを提供します。

物理的なヌルテスト実行の測定結果は以下の通りです。

最悪のブロックは利用可能な時間の88.45%を使用し、57,740サイクルを残して完了しました。

ステージングされたレイヤーメジャー実装と手書きの2フレーム浮動小数点畳み込みカーネルもテストしました。これらは、48サンプルブロックあたりそれぞれ662,042サイクルと1,001,381サイクルを消費しました。どちらもオーディオの締め切りに間に合いませんでした。

私が測定した最も高速なバージョンは、ポータブルな全体モデル浮動小数点エンジンでした。2サンプルをまとめて処理することは、畳み込み重みを再利用することを意図していましたが、完全な実装はより多くのサイクルを消費しました。これらの測定は遅延を確立しましたが、中間メモリトラフィック、関数呼び出しオーバーヘッド、または命令スケジューリングからどれだけ遅延が生じたかを特定したわけではなく、キャッシュミスが原因であることも確立しませんでした。遅いバリアントを削除し、時間内に完了したバージョンを保持しました。

その後、ライブバッファを16フレーム、つまり0.333ミリ秒に削減しました。その締め切りは166,667サイクルです。最終的なファームウェアは、遅延したブロックをストリーミングし続けます。4つのエントリを持つDMAキューのいずれかが遅延した場合、両方のSAIストリームを再起動します。障害が発生すると、可聴クリックまたはドロップアウトが発生し、再生が再開されます。

インターフェースをペダルに変える

交換されたファームウェアは、I2C経由で元のコーデックを設定し、eDMAを使用してSAIでステレオオーディオをストリーミングします。完了した各入力ブロックは浮動小数点に変換され、A2-Liteにフィードされ、再度変換されて再生のためにキューイングされます。2番目の出力チャンネルは同じ処理済み信号を運び、ヘッドフォンとアンプのパスが正常に機能するようにします。

物理的なホイールは引き続きヘッドフォンのレベルを設定します。最初のライブビルドが痛いほど大音量になったときに、これが緊急になりました。ホイールが再び機能すると、元のインターフェースのように演奏できました。

ライブモードでは、USBケーブルがHD Xに電力を供給します。オーディオは基板上に留まります。

1. コーデックが48kHzでギターをサンプリングします。
2. eDMAが16フレームの入力ブロックを埋めます。
3. A2-Liteが5150キャプチャをレンダリングします。
4. eDMAが結果をコーデックに送り返します。
5. ヘッドフォンとアンプの出力がそれを再生します。

iRigにギターとヘッドフォンを接続し、信号パスにホストコンピューターがない状態でモデルのサウンドを聞きました。USBインターフェースは、ペダル全体になっていました。

上流のNAMCoreとの比較

元の.namキャプチャを使用して、上流のNeuralAmpModelerCoreで同じ15秒、48kHzのギター録音をレンダリングしました。一時的なiRigファームウェアは、比較のためにRT1011の処理済みサンプルをUSB経由で返しました。録音後、ライブファームウェアを復元しました。

物理的なiRigと上流のNAMCoreはゼロサンプルで一致しました。最初の1秒後、安定したレンダリング部分のヌルは次のとおりです。

4つのファイルをすべて聞く

起動時を含む、15秒間全体での相対ヌルは−115.70 dBでした。最大の誤差は、フルスケールの数百万分の1でした。これは、異なるコンパイラとプロセッサからの浮動小数点丸めであり、コーデックのアナログノイズフロアよりもはるかに低い値です。

デスク上のボックスは今や違う

iRig HD Xは、ギターとどこかで実行されているソフトウェアの間のブリッジとして販売されています。このデバイスは、独自のオーディオループ内でアンプモデルを実行できます。

完成した研究ビルドには、以下が含まれます。

• 実際のNAM A2-Liteエンジン。
• 独自のフラッシュに保存された5150 + OD808キャプチャ。
• 16フレーム、0.333ミリ秒ブロックでの48kHz処理。
• アンダーラン後の永続的なサイレンスの代わりに自動SAI/eDMAリカバリ。
• 元のコーデック、入力、出力、およびボリュームホイール。
• 上流のNAMCoreに対する−115.63 dBのヌル。

この旅は、間違ったUSBインターフェースをESP32-S3と通信させようとすることから始まりました。約12時間後、インターフェースはアンプサウンドを単独で生成できるようになりました。