FireWireオーディオについて

RME Firefaceシリーズは、サードパーティー製のオールインワンFireWireチップを使用しない唯一のFireWireインターフェイスです。 例えば、他社のFireWireインターフェイスは下記のチップを採用しています。

• BridgeCo 社製： M-Audio、 ESI、 Edirol、 Presonus、 Apogee、 TASCAM
• Philips 社製： MOTU、Hercules
• Texas Instruments 社製： Echo、Mackie

一般的なFireWireインターフェイスのオーディオ処理

オーディオデータを処理するRISCプロセッサ、リンクレイヤーが1基のチップ上にあります。RISCプロセッサでのDSPはパフォーマンスに問題があるため、その代わりにDSPを外部に接続して処理を分散しなければいけません。外部でのDSP処理による主な難点は、DSPとFireWireコア間での転送レート（帯域幅）が限られていることで、チャンネル数に大きな制限があります。また、通常、リンクレイヤーの構成を変えることができるのはチップメーカーが新しいファームウェアを提供するときだけです。

Firefaceのオーディオ処理

Firefaceは、RMEが独自に開発したFireWireオーディオ・コアを採用しています。サードパーティーのFireWireチップの代わりに、オーディオ専用のFPGA（Field Programmable Gate Aray：プログラミング/書き換えできるLSI）でデータ処理とDSPを行います。

DSP はこのFPGA内にあるので、DSPとFireWireコア間での転送レートに左右されません。Hammerfall DSP同様に、TotalMix、レベルメーターのような処理を最速のRAM(内部のセル)で行います。このDSPは、例えば、HDSP MADIの全チャンネルをTotalMix(8192系統の同時ルーティング演算)で処理してもまだ余裕があるほどの能力です。

Firefaceが使用するリンクレイヤーとフィジカルチップはTexas Instruments 社製です。このチップセットは、Firewireの開発元Apple Computerで採用されている以上、最大の互換性があるべきです。

リンクレイヤーはFPGAに接続されていますので、両方のチップの仕様内で無制限のコントロールが行えます。

他のFireWireインターフェイスでは難しい、周辺機器との互換問題修正、バグフィックス、機能の改良は、FPGAのフラッシュアップデートによりフレキシブルに行うことができます。

プロオーディオ専用機

オーディオ専業ではないサードパーティー製のチップは、後のファームウェアアップデートでも、プロオーディオ用の機能の追加が困難です。Firefaceは、プロの現場で求められる多くの下記のような機能をすでに備えており、今後さらに追加することもできます：

• リアルタイムで外部信号へ自動的にロック/シンクする同期コントロール
• 極端なバリピッチの外部同期信号もサポート
• アプリケーションでオフセットがまったく必要ない録音/再生
• 複数台の使用
• 最大192kHzのサンプリングレートサポート
• リアルタイムでのバッファサイズ変更

RMEのFireWireによる独自機能

データパケットのチェック

データパケットのチェックとドロップアウトの修正は特筆すべき機能です。DAWが、クリックノイズやドロップアウトを起こす原因に2つの理由があります:

• オーディオエンジンにデータ処理の十分な時間がないこと。バッファサイズ（レイテンシー）を増やすことで解決できます。
• PCIバスの性能が追いつかずオーバーロードし、データを損失すること

すべてのWindowsマシン（IBM PC/ATI 互換機）のFireWireは、PCIバスの「上」に接続されていて、FireWireバスを統合したチップセットはありません（Macintoshは FireWireを統合しています）。そのため、Fireface 800のリリース後、後者の原因が以前よりしばしば発生しています。つまり、OHCIのチップは、Hammerfall DSPのPCIカードほどPCIバスのパフォーマンスにシビアでないため、バスのオーバーロードによる問題も起こりやすいのです。Hammerfall DSPのようなDMA（PCIバスマスター）技術とは異なり、FireWireを使用しての低レイテンシー使用では、コンセプトをいかなるノイズやデータの損失を防ぐ「安全」という概念に切り替えが必要です。

Firefaceには、CPUのオーバーロード（レイテンシー/バッファサイズの問題)が原因か、バス帯域のオーバーロードが原因かを、簡単に見分ける方法があります。
コンピュータとFirefaceとのFireWire接続内に、透かしパケットを含めることで、いつ、どのくらいのデータが損失したかを検出します。そして、右の画像のように、 Fireface Setting上に検出されたエラーの数を「動画で」　表示します。パケットに全く損失が無い場合には、表示されません。新しい再生が始まるごとに、表示はリセットされます。

この伝送エラー表示によって、DAW用コンピュータのパフォーマンスがチェックできます。これは、RMEのドライバでは改良できないコンピュータ自体のパフォーマンス（マザーボードやFireWireコントローラの組み合わせで引き起こされるもの）です。
例えば、Firefaceとオーディオ機器を立ち上げ、次に、Windows、ドライブ、ネットワークを起動してそのままにしてみてください。このとき、Fireface Settingsにエラー表示がでまったく現れないなら、少なくともオーディオ環境には、そのマシンが完全に適している信頼性のあるマシンといえます。もし、エラー表示がなくてもクリックやドロップアウトが発生する場合には、そのマシンは、DAWでリアルタイムでオーディオを扱えるほど強力でないかもしれません。

ドロップアウトの修正

上記のように、データパケットが損失するときには、その失われたサンプルの量に従って現在のサンプルの位置がシフトします。安全のために増やしたバッファが消費されると、アプリケーションはバッファを処理するのをための時間が全くありませんので、その位置がとても重要になってきます。最小のCPU負荷の場合でさえも、CPUに100%の負荷がかかっているような、完全なひずみに聞こえます。次に、その位置が巻いていくことでレイテンシーは劇的に上昇してしまいます。

この現象に頻繁に悩まされるとき、新しいコンピュータを導入することも解決策ですが、Firefaceにはこのような状況でもベストの結果を出す機能があります。

このような問題を解決するには、いくつかの選択があります:

• ハードウェアを停止します。これで乗り切れるかどうかは、オーディオアプリケーションの安定性に依存します。
• ハードウェアを停止し、まもなく再起動します(約1秒間停止します）。以前よりパフォーマンスは良いですが、まだ、オーディオアプリケーションでのトラブルの可能性が残っています。
• できるだけ頻繁にハードウェアを停止して、再起動します。

それはまさにRMEがしていることです。Firefaceは、およそ3ms （！）間オーディオを停止し、パケットの損失やドロップアウトのすべての場合に、サンプルの位置をリセットします。これはRME独自の傑出した特長です。
迅速なリスタートによって、記録されるデータの位置さえも修正されます。例えば、NuendoやCubase SXで5分のトラックを録音して、そして、故意にPCIオーバーロードを引き起こしたとします。その結果、記録されたwaveファイルは3msのミュートされたオーディオセグメントを含むことで、それ以下のすべてのオーディオのサンプルはまだ正しい位置にあります!
3msのドロップアウトであれば、通常耳には聞こえません。理論的にも、開始時に数サンプルを、停止時にミュートのセグメントを加え、手動で修正、またはコピーでミュートのセグメントを満たすことで、たとえ短いドロップアウトがあった場合にも完全に修正することができるのです。まさに、録音に失敗できないプロの現場に堪えうるための傑出した機能です。

FireWireオーディオのリファレンス・モデル

RME は、後発でFireface800をリリースしたにもかかわらず、すぐにFireWireオーディオの分野でもリーダーになっています。それは、オーディオ業界のプロが求めるHammerfall DSPの仕様を引き継ぐポリシーがあるからです。他社のインターフェイスは固定チップのアップデートを待たなくてはいけませんし、おそらく現在の Firefaceの仕様を追加することは難しいでしょう。しかし、1基のチップに依存しないFrefaceは、常に新しい機能を追加できる可能性を秘めています。Firefaceは、当面の間、FireWireオーディオのリファレンス・モデルであり続けられると自負しています。