#38 USB Audioについて（その6 Host側のドライバについて）

　前回の記事（#37）について早速「えるえむ」さんからコメントをいただきましたので、その回答も兼ねてHost（PC）側がどのようにして音楽データをUSB_Bus上に送り出しているのかということについて簡単に説明しておきます。Host側の動作を理解していただいた上でJitterなどの話を進めたほうがわかりやすいと思いますので。

＜図-38-1 USB Audio 関連Softwareの階層＞

　USB Audio 機器ベースのPC_Audioに関係しているドライバ、アプリケーションソフトウェアの構造を簡単に示したものが図-38-1です。このような階層構造(OSI)は25年以上も前に大型計算機の通信ソフトウェアで使われてきたものです。同図はWindowsPCの場合ですが、MacOS XやSolaris,Linuxも同じような構造をしています。一番ケーブルに近いところはハードウェア（USBコントローラLSI）でPCI_BusやCardBusスロットを経由する場合もあります。最近は大半がMother Boardに実装されているChip Set（LSI）に組み込まれ、内部のSouth（PCI） Bridge経由でCPUのBusに接続されています。これらのコントローラにはLowSpeedとFull Speed（12Mbps、USB AudioはUSB 2.0と称していますが、ほとんどの製品はこのFull Speedで動作しています。）を受け持っているUHCIあるいはOHCIアーキテクチャのコントローラ、High-Speed（480Mbps、昔の呼び方ではUSB 2.0）を受け持つEHCIアーキテクチャのコントローラの3種類があり、それぞれに対応したミニポートドライバがWindowsやMacOSなどのOSに既に組み込まれています。ちなみにWirelessUSBの場合はWHCI、SuperSpeedUSB（USB 3.0）の場合はXHCIと呼ばれます。IEEE1394の場合もOHCIアーキテクチャと呼ばれています。

　RAL-2496UT1などのUSB Audioの場合はUHCIかOHCIアーキテクチャのコントローラ経由で通信することになります。UHCIというのはintelが提唱したアーキテクチャでintelのChip Set以外ではVIAのChipで使用されており、ほとんどの処理をSoftwareによるポーリングで行うので構造が簡単ですがソフトウェアのオーバーヘッドが大きく、リアルタイム処理向きではありません。対抗するOHCIはOpenの頭文字が示すようにCompaq,NS,Microsoftによって提唱され、NECやNvidea、AMDなど多数の会社が採用しているアーキテクチャで、ほとんどの処理をコントローラ自身が自分で行います。Software（CPU）はDescriptor ChainをSetしてコントローラに実行指令を出すだけでよいのでリアルタイム向きで優れているのですが、その分コントローラの設計が難しくなり構造も複雑ですので価格が高くなります。実際にOHCIアーキテクチャが使われているChipはAMD-CPU用のChip SetおよびNECのUSBコントローラChipです。

　USB DACなどのUSB Audio出力ではIsochronous転送が使用されていますので、全体のCPU負荷が小さければOHCIでもUHCIでも動作に差はありませんが、音楽編集や録音、Mixingなどでインタラプト転送、コントロール転送、バルク転送などが使用されている場合はUHCIよりはOHCIの方を使用したほうがよい結果が得られると思います。なぜなら、OHCIでは32mSごとに最低1度はインタラプト転送を受け付けたり、1フレーム期間内に複数のコントロール転送や2回以上のバルク転送を実行できますがUHCIではこれらは実行できません。

　USBポートにUSB機器が接続されるとまずLow SpeedかFull Speedかが2本の信号線(D+とD-)の状態で判断されます。続いて、USB機器の種類や属性を引き出すためのGET_Descritorが発行され、機器側はDevice Descriptorを返送します。Descriptorを解析した結果USB Audioの規格に準拠したAudio DeviceであることがわかればAudio Class Driverとしてusbaudio.sysがロードされます。続いてDevice Managerによって、その上にKernaelmixerあるいはASIOなどの中間のDriver(Client Driver)がロードされます。さらにその上にiTunesやMedia Player, foobar2000などのアプリケーションがユーザー（みなさんです）によってロードされれば、最終的に図-38-1のような階層構造が出来上がります。

　この図からおわかりのようにRAL-2496UT1などのUSB Audio機器はASIOドライバから見て、下位のusbaudio.sysを経由してにアクセスされますので「USB Audio規格に準拠しているUSB Audio機器は基本的にASIOドライバに対応している」ということになります。したがって、iTunes（QuickTime Player）などのアプりケーションがASIOドライバを使用するようにアプリケーションの入出力を設定すればOKです。その設定を行わなければKernelMixerが有効になりますのでRAL-2496UT1などのUSB Audio機器へのアクセスはKernelMixor経由となります。Windows Vista SP2以降（Windows 7も）では従来のDirectX(Sound)だけでなくKernelMixer内部の機能を選択(パススルー)することができるWASAPI（Windpws Audio Session APplication Interface）というAPIが新たに用意されていますので、これを使用してUSB Audio Deviceを排他モードに設定し、bit数やfsをWAVファイルのヘッダ部に書かれているものを指定するという方法もあります。もっと、簡単な方法はUSB Audio DeviceのDescriptorの記述を16bit/44.1kHzのみなどにしてしまうという方法もあります。この方法で16bit/44.1kHzのWAVファイルのみを再生すればKernelMixer内部のSRC機能を実質的にPassさせることができると思います。FostexのHP-A3の場合は、Descriptorに16bit/96kHzと24bit/96kHzにのみ対応としか記述されていませんので、KernelMixerなどのSRC機能を使用せずに16bit/44.1kHzのWAVファイルをオリジナルとおりに再生しようとするとPC側でエラー表示がでて再生できません。したがって、先ほど「USB Audio規格に準拠しているUSB Audio機器はASIOドライバに対応している」と書きましたがUSB Audio機器側がSRCなしでASIOドライバを通して送り出されて来る音楽データのbit数/fsに対応していなければなりません。RAL-2496UT1では16bit、24bitの各解像度で44.1kHz,48kHz,88.2kHz,　96kHzの各fsに対応していますのでWASAPIやASIOドライバを使用すれば、PC側のSRC機能なしでたいていのWAVファイルやAIFFファイルをそのまま再生できます。iTunes（QuickTime）のWASAPI使用の設定方法についてはラトックプレミア楽天市場店の店長Blogを参照してください。

＜図-38-2 WAVファイルがUSB転送のためのIsochronous Out パケットに編集されるしくみ＞

　図-38-2をご覧ください。iTunesなどのアプリケーションは指定されたAIFFもしくはWAV（どちらも非圧縮PCM）ファイルをHDDやSSD、FlashMemoryなどの記憶媒体から読み出してRAM上で編集します。編集といっても簡単でファイルのヘッダに格納されているfmtチャンク(format情報。chunkは'ぶつ切り'のひとかたまりという意味です)内部のbit数（L,R各チャンネルあたりの）やfs情報を元に、dataチャンクから取り出した実際のサンプリングデータのブロックを下位のドライバに引き渡すだけです。usbaudio.sysではこの上位から渡された10mS（10フレーム）分のデータブロックを各フレームのパケット用にfs/1000組ずつ（44.1kや88.2kの場合の分け方は#37参照）整列させます。OHCIの場合にはとても簡単で各パケット分のデータと荷札（Packet-IDと順番、Timestampなどが記載された）、次のメモリブロックの場所を記載した送り状をひとつのメモリブロックに格納してチェイン上に並べておきます。そしてOHCIコントローラに最初のメモリブロックの場所を指示して実行命令を出しておけば後はOHCIコントローラが内部のインターバルタイマの1mS間隔にしたがって、USB Bus上に送り出してゆきます。UHCIコントローラのミニポートドライバは作ったことがありませんのがこんなに簡単（CPUのすることが少ない）ではないようです。

　この図からおわかりのようにHost（PC）側ではfsによるサンプリングなどは行っていません。サンプリングされたデータ列をデータが作成されたbit数、fsに基づいてRAM（メモリ）上で整理しているだけです。サンプリングレ?トや解像度を変換しない限り非圧縮のPCMデータに対してはbitの追加や変更などは行いません。また、HDDなどの記録媒体に関係なくRAM上に読み出されたデータは同一です。　したがって、「HDDなどの回転体を使用するとJitterが増えて音が悪くなる」とか「PCのClockがゆらいでJitterが増える」、「PCのClockがUSBケーブルを通ってUSB Audio機器側のfsに影響する」というような評論記事はすべて???です。実際の再生はUSB Audio機器内部で作成したClockによりAudio信号に変換されます。したがって、再生時（I2S作成時）のClockはデータ送り出し側とは完全に独立していますのでAsynscということになりますが、曲の最初を同期させなければ正しく再生できませんので何らかの方法が必要です。そこだけに注目するとSYNCということになり、Isochronous転送は受信が終わるまでバイト数がわからず、しかもそのバイト数でしかfsを判断できないということを考えればAdaptiveということにもなります。要はIsochronous転送の動作モードの指定はどうでもいいのです。プロトコルアナライザで観測している限りでは動作モードbitをいろいろ変えてみても何も変わりません。

　USB Audioで問題なのはいろんなアプリケーションが動作している場合、Isochronou転送用のパケットが用意されていないことがあるということです。また、WindowsもMacOSもUSBのミニポートドライバなどが特権モード（Kernelモード）から優先度の低いユーザモードに移されてしまいましたので、PowerManagementなどの特権モードで動作するドライバにPacketデータのセットが邪魔をされてしまうことがあります。これらの問題が「ブチッ！」という再生時の音切れの原因のひとつになります。実際にWindowsVistaではNEC製USBコントローラを使用した私たちの製品（PCIボードおよびCardBus Card）の動作が非常に遅くなります。いろいろ調査したところMicrosoftのPowerManagementドライバが常時USBコントローラ（OHCI/EHCI）を監視しておりバルク転送などの動作の邪魔をしていることがわかりました。でもMicrosoftからは「悪ぃ、悪ぃ、Windows7では直しておくよ」という回答でした。約束通りWindows7では修正されていますがVistaユーザはどないすれば….

　同様にMicrosoftではIsochronous Packetへのデータセットが間に合わずに発生する音切れ（Scratch noise like a vinyl recordというらしいのですが）について統計を取って調査をしています。その結果、この音切れを発生させる最大の要因はPowerManagementであり、ノートPCをバッテリで動作させている状態が最も発生しやすいとの結果を発表しています。「PC_Audioで最もいい音を出すにはノートPCをバッテリ駆動で動作させる」という記事をよく見かけますが、これは音切れの発生率が最も高くなることがあるということに気をつけてください。

　余談ですがintel-Macが発表される1年くらい前にMacOSでもUHCIをサポートするということが発表されたことがあります。その事実が示すようにintel-MacのUSBポートはUHCIアーキテクチャを採用しています。OHCI用のドライバはまだ残されていますのでPCIeボードを使用すればOHCIアーキテクチャが使用できますが、NECのUSBコントローラ搭載のPCIeボードはありません。NECのUSB 3.0コントローラ搭載のPCIeボードでEHCIとOHCIを使用するという手はありますが、USB 3.0のDriverはまだ提供されていません。通信用のファームウェアを書くたびにMC6800系はよく出来ていたのになぁ~と懐古趣味に浸っています。でも、このScratchノイズが解決すればUSBはPC_Audioの信号伝達手段として最も普及すると思います。

　次回はJitterについて説明します。