#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について説明します。

Comments

[投稿情報: A/T]

いつも大変に参考になる内容を公開頂き誠にありがとうございます。
質問です。

『WindowsXP SP2以降（Vistaや7も）では従来のDirectX(Sound)だけでなくKernelMixer内部の機能を選択(パススルー)することができるWASAPI（Windpws Audio Session APplication Interface）というAPIが新たに用意されていますので、』

以上の記述がありますが、巷でWASAPIは「Vista SP1以降で使用可能」と言われているようです。私がネットで検索した限りでもXPで使用している例は出てきませんでした。
WindowsXP SP2もしくはSP3で使用する方法があるのでしょうか？
Windows7のディスクがあるので利用できるか？と色々やってみましたがチンプンカンプンでした。
よろしくお願いいたします。

[投稿情報: 作者]

A/T様
　ご指摘ありがとうございます。XPという記述は誤りで正しくはご指摘のとおりVistaです。いつもXPを使用しているので、Vistaと書いたつもりが間違えてしまいました。申し訳ございません。

[投稿情報: ばたやん]

ブログを書いておられたのは社長さんだったとは驚きました。
本日インプレスのインタビュー記事を拝見しました。
実際の測定でジッターが少ないということは分かったのですが、他社製品と比べ何処が違うかということはあの記事では良く分かりませんでしたので、次回こちらで詳しく解説して頂けると幸いです。

さて今回のブログの内容に関して質問させて頂きたいと思います。

>UHCIよりはOHCIの方を使用したほうがよい結果が得られると思います。

Intelのチップセット内蔵のUSB端子を使用するよりも、貴社のUSBボードを増設して使用した方が良いということでしょうか?
また、USBオーディオ用途では、USB2.0とUSB3.0のボードのどちらが良いのでしょうか？

>WindowsVistaではNEC製USBコントローラを使用した私たちの製品（PCIボードおよびCardBus Card）の動作が非常に遅くなります。

XPでの動作は大丈夫でしょうか？

以上2点宜しくお願い致します。

[投稿情報: 作者]

ばたやん様
　コメントありがとうございます。
　UHCI vs OHCIの件、本文にも書きましたがFull SpeedのIsochronous Out転送では同じです。DTMの録音やサンプリングなどのIsochronous IN転送では差が出るかもしれませんが。
　24/96までの現行のUSB Audio Spec 1.0準拠のレベルではFull SpeedですのでEHCIもXHCIもH/W的に切り離されますので関係はありません。
　NEC製コントローラがPowerManagementによって悪さをされるのはVistaのみです。本文にも書きましたがXPや7では問題はありません。

[投稿情報: ばたやん]

作者様
御返事有難うございました。
しつこいかもしれませんが、もう少し詳しく教えて下さい。

下記の御回答に関して、
>UHCI vs OHCIの件、本文にも書きましたがFull SpeedのIsochronous Out転送では同じです。

しかし本文では微妙で、
>全体のCPU負荷が小さければOHCIでもUHCIでも動作に差はありませんが、

OHCIはバスマスタなので、CPU負荷が高い場合にはUHCIよりも良いということにはならないのでしょうか？

REX-PCIU3を購入しようかと考えておりましたが、余り意味はありませんでしょうか？
また、XPで使用の際には、OS標準ドライバと貴社専用ドライバがありますが、オーディオ用としてはどちらが良いでしょうか。

以上宜しくお願い致します。

[投稿情報: 作者]

ばたやん様
　返信が遅くなり申し訳ございません。UHCIのDriverを書いたことがありませんので詳細は不明ですが、いくらなんでも20年前のNetworkボード(NE2000)のようにOUTS命令で転送はしていないと思います。DMACかバスマスタですのでInterrupt転送への応答やBulk転送(Packet数の上限)以外は同じと思います。Isochronousパケットの欠落について実際にUHCIとOHCIを比較しながら調査したことがありませんので正確なことはわかりません。音楽を聴いている途中でバチッという音が少ないPCとI/Fの組み合わせをご自分で判断して下さい。PCIU3用のDriverですが当社が提供しているものはEHCIのDriverです。したがって、usbaudio（Full Speed)のIsochronous転送時にはバイパスされますので「音」とは関係ありません。