Fireface UCの開発：USB伝送方式とOS対応の課題
Fireface UCの開発には1年以上を費やしました。他社からは様々なUSB2.0デバイスが発売されていますが、USB2.0の高帯域幅（480 MBit/s）や下記に示すような複数の伝送手段等、様々な可能性やパフォーマンスを持ちながら、効果的なデータ伝送方法が確立されていません。我々はこれらのデバイスとは全く異なる方法で、より良い製品を開発する為に一から取り組みを始めました。
- アイソクロナス伝送
- 高帯域幅モードにおけるアイソクロナス伝送
- アイソクロナス伝送 + 割り込み伝送
- 割り込み伝送
- 高帯域幅モードにおける割り込み伝送
- バルク（ディスクデバイスと同様の一般的なデータ伝送）
我々は汎用のチップに依存せず、独自のFPGA（以下参照）の中にUSBを実装させたことで、これらの伝送方法を詳細に検証することができました。しかしながら、検証結果はほとんどの場合、失望的なものばかりでした。OSの不十分な対応が原因で（例えば高帯域幅モードにおける割り込み伝送への対応）、理論的に最善と思われる手段が、現実的にはうまくいきませんでした。理論的には、192kHzの低レイテンシー・マルチチャンネル伝送には高帯域幅モードにおける割り込み伝送が最適ですが、WindowsもMacもこれに対応していません。このUSBモードはおそらく実装されていないのでしょう。
このような問題から我々は何度も設計のやり直しを強いられました。録音にアイソクロナス伝送を導入し、プレイバックに割り込み伝送を採用したミックスの設計も試しました。しかし、回路が現実的に安定したにも関わらず、高いCPU負荷を含む様々な問題が発生したりもしました。
OSに対する最適化とFPGA
最終的に、2つの可能性が残りました。結論としてWindowsシステムにおいては、割り込み伝送方法が最適だとわかりました（ASIO低レイテンシーの割り込み要求が別々に伝送される場合に限って！）。これはUSBでは不可視的に行われます。この方法を採用しているメーカーは我々だけではありませんが、テストした結果どこよりも効率的、効果的にこれを実現しています。また、WindowsにおけるWDMの制限をも克服しました。Windowsにおいて256サンプル（XP、Vistaの場合は512）を超えるバッファーサイズは制限され、それを超える場合歪みが発生しますが、Fireface UCは最大2048サンプル（シングルスピード）による安全な動作を現実的に可能にしています。
結果として、Fireface UCはひどい環境にも耐えうる性能を実現しています。例えば私の使用しているコンピュータDell Studio 1537は良い例です。このコンピュータは5秒毎に4msのフル・ハードウェア・ストップがなされます。いわゆるDPCレイテンシーと呼ばれるこの数字はDPC Latency Checkerで計測することができます。
この場合、4ms（現実的には8ms）以下のレイテンシーでは使用不可になることを示しています。このDellコンピュータで、RMEのUSBの実装による優位点が明確に確認できます。
- エラーの無いプレイバックにはWDMの場合でも最低256サンプルが必要（RMEの特別なUSBでは2048サンプルまで対応）
- 伝送エラーは、Settingsダイアログに大きいエラー、小さいエラーと別々に表示するため、適切なバッファーサイズを設定でき、正常な動作を監視できます
- 自動エラー補正機能によってノイズやドロップアウトを防ぎます（エラー発生時の最善な手段）
Macにおいては「通常」のアイソクロナス伝送が採用されています。Mac OSはUSBオーディオに理想的に設計されています。WindowsコンピュータではCPU負荷が高い状態で低レイテンシー動作は現実的に不可能ですが、Macでは可能です。しかしここでもRMEはUSB伝送のさらなる最適化を行い、全体的なパス・スルー・レイテンシーで数サンプル短くしています。内部のUSBレイテンシーは12サンプルのみ（我々の知る限り他社製品では最低 16サンプル）で、セーフティーオフセットは２４サンプルです（Fireface 400/800では64サンプル）。
WindowsとMacにおいて異なる伝送モードが採用されているため、Fireface UCは複数のファームウェアを導入しています。バックアップ・バージョン（ファームウェアアップデートの失敗やテスト用のスペア）を含めると一台につき4つのファームウェアを搭載している事になります。
両方のOSヘの最適化、パフォーマンスを向上させる技術開発は、FPGA上でUSBを実装させることで可能になりました。これによって他社メーカーがアクセスすることができない、ユニットの動作、パラメーターを完全に管理することができます。さらに、将来的にWindows 7や8、もしくはMac OSの時期モデルが発売され、他の伝送方法の方がより良い動作をする状況になったとしても、お客様はファームウェアアップデート行うだけで対応させることができます。よってFireface UCは、それがUSB2.0であれば、いかなるOSにも最適化できる訳です。
FireWireでの経験を活かした設計：FPGA実装による互換性と将来性
我々は既にFireface 400と800の開発においてFireWireオーディオの実装について報告しており、これによってRMEならではの動作（バリスピード、設定のリアルタイム変更、バッファーサイズや周波数、エラー表示等）を確立することができました。
ダイアグラムに表示されるとおり、Texas InstrumentsのFWコントローラーは、Link Layerコントローラーとして使用されています。FireWireプロトコルは独自の開発には複雑すぎたため、我々はTIが安全で互換性の高いソリューションであると判断しました。これは適切な判断でした。しかし、Apple社はコストを削減する為にLSI/Agereのチップを採用しました。このチップは、アイソクロナスモードにおいて不具合の多いチップであり、TIの様なデファクトの業界標準とはほど遠いものでした。結果、我々のお客様はFireWireのハブやリピーターを購入する事を強いられました。しかし最近ではApple社は不具合の解消されたAgereチップを採用しこれらの問題を解決しています。
このような体験をしたことで我々はFireface UCに安全策を講じることができました。Fireface UCにおいてはUSB 「LLC」つまりUSBコントローラーチップは搭載されていません。物理的なインフターフェイスのみを採用して、インターフェイスのボルテージやインピーダンス等のパラメーターを調節し、480MBit/sのシリアルデータストリーム入力をコンバートしてパラレルでFPGAに送ります。安いチップとの互換性の問題などは一切生じません。例え互換性のない独自のUSB規格の解釈を行うUSBコントローラーが現れたとしても、RMEのプログラム可能なメインチップ内で全てのUSBプロトコルが処理されるため、ファームウェアアップデートによって対応させることができます。
