2010年明けましておめでとうございます。
本年もよろしくお願い申し上げます。
今年はPC_AudioやUSB Audio, Network Audioが昨年よりももっと盛んになりそうな予感がします。海外のSoftware屋さんやHardware屋さんに負けていられませんので今年もCESを見に行くことにしています。また、Digital Audio関係の仕事をしている新しい半導体設計ベンチャー企業を見つけに行くために私たちの現地法人のあるSilicon Valleyにも立ち寄って来ます。
前回はUSB機器（Device）が備えていなければならないDescriptorの先頭部について説明しました。今回はUSB Audio Device固有の部分、さらにそのAudio Deviceがサポートしているformatなどの情報が記載されている部分（Interface Descriotor）について解説します。これらのDescriptorはAudio Deviceには必須で記述を間違えるとusbaudio.sysがloadされなかったり、USB Audio Deviceとして正しく設定されません。Device Managerで見ると「USBオーディオデバイス」が登録されていないあるいは黄色の'!'マークが付けられてしまうという結果を引き起こします。 usbaudio.sysがLoadされなかった場合やUSBオーディオデバイスとして正しく設定されていない場合は、iTunesやMedia Playerなどのアプリケーション、ASIOやKernelMixerなどのミドルウェアから無視され、USBポートからはAudio Data Streamが出力されなくなります。さらにInterface Descriptorは16bitあるいは24bitというAudio Dataの分解能を指定するためにも使用されますので、この部分は非常に大切です。
（１）Interface Descriptor #0 （Audio Terminalに関するDescriptor）
前回の図-2を参照してください。前回はConfiguration Descriptorまで解説しましたので、46行目（申し訳ありません。前回のリストはusbviewのハードコピーですので行番号が入っていません。）、MaxPowerの次にInterface番号0に関するInterface Descriptorが記述されています。これはAudio Deviceが備えている機能に関する記述で、ClassやSub Classに関する記述、ヘッダ部、入力機能、出力機能の順に記述されています。
最初の部分にはInterface ClassがAudioであることを記述しています。この記述が正しくないもしくは存在しないとUSB Audio DeviceとしてHostに認めてもらえず、WindowsPCの場合はusbaudio.sysがLoadされません。
次のInterface Sub Classは表-34-1のように4種類のCodeが決められています。RAL-2496UT1の場合はVolumeや再生、停止、巻き戻しなどの制御ボタンを持っていることをHostに通知するためにAudio Control（0x01）をsetしてあります。実際にS/PDIF出力のVolumeをHostから制御したり、制御ボタンを持っているわけではありませんがTerminalに関する記述を行う場合にはこのCodeをSetしておくのが一般的です。
＜表-34-1＞Audio Interface Subclass Codes
その次の部分はusbviewのコメント出力では"Audio Control Interface Header Descriptor"となっていますので、日本語のコメントもそれに合わせてありますが内容は"Audio Class-Specific Descriptor"（Audio Class 固有のDescriptor）です。Descriptor Typeが0x24ですので、Audio Class Interfaceに関するDescriptorであることがわかります。Sub Classは0x01ですので表-34-2からHeaderに関する記述で、その次のADC（Audio Device Class Specc）が0x0100ですので、Audio Device ClassSpec. 1.00準拠ということになります。
Header部の次にInput Terminal（入力）に関する記述を行います。Descriptor Sub Typeには表-34-2からInput_Terminalを示す0x02を選択してsetしています。注意すべきなのはUSBの場合、DeviceはHostに対して従属関係にあることおよび信号線がD+,D-の2本一組で方向を切り替えて一方通行の通信を行うため、HostからのRequestやCommandがないと何の通信も行ってはいけないことになっています。したがって、IN、OUTという表記もすべてHostを基準に決められており、OUTというのはHostからDeviceへの方向、INというのはDeviceからHostへの方向を示します。ただし、本Descriptorの場合は、AudioTerminalに関する記述ですので、Audio Terminalの入力、出力を規定します。したがって入力はHostからのUSB Streamingであるということを記述します。これらの関係（topology）は図-34-1を参照してください。このTopologyをWindowsやMacOSに認識してもらうためにUSB Device Descriptorを正確に記述しなければならないというわけです。Plug & Playは使う方はとても便利ですが、つくる方は大変なのです。
＜図-34-1＞USB TransportのTopology
Output Terminalに関する記述も同じようにDescripterTypeは0x24、Sub TypeはOutput Terminalを示す0x03とし、TerminalTypeは0x0605（S/PDIF）としておきます。TerminalTypeは今のところDevice Managerなどで表示されるi-conと名称に反映されるだけで、それ以外は特に参照されてはいません。RCA-JackによるAnalog Outとする場合は0x0601をSetすればOKです。
（２）Interface Descriptor #1（USB Audio Stream 受信機能に関する記述）
Configuration DescriptorのNumInterfacesが0x03でしたので、RAL-2496UT1は3組のInterface（#0,#1,#2）を持っているということをOSに通知しています。#0は上記のAudio Terminalに関するものでした。#1はAudioらしい、bit数、fs（Sampling周波数）などを記述したDescriptorです。このInterface Descriptorは3個のInterface Setを含んでおり、それぞれMute用（音声出力停止）、16bit Stream用、24bit Stream用という役割分担をしています。そして、これらのInterface Setはusbaudio Classのさらに上位のClass Driver（Kernal Mixer, QuickTime Player, ASIO など）やiTunesなどのApplicationから曲の演奏開始前や停止時にbit数を指定するためや、Audio出力を停止するためにSet Interface Requestで使用されます。ただし、別稿で説明しますがUSB Audioの規格では、fs（Sampling周波数）の指定はSet Interface Requestではなく、1フレームの間（1ms）に送り出されるUSB Audio Streamのサンプル数によって行われます。もし、Set Interface RequestによりUSB Audio Device側のbit数とfsを同時に指定する場合はApplicationやDevice Driverを独自仕様で作成してInstallしておく必要があります。
Interface Set#0（AlternateSettingが0x00）は音声出力停止用のDescriptorです。この場合はNumEndpointsを0x00にSetしておき、Isochronousパケット受信用のEndpointを使用しないことを記述しておきます。Endpointが使えないため、HostはAudio Data Streamを送ってきません。
Interface Set#1（AlternateSettingが0x01）は16bitのAudio Data Stream用のDescriptorです。Audio Data Streamを受信するためNumENdpointsを0x01にSetし、Isochronousパケット受信用のEnd Pointを使用すると記述しておきます。それに続いてAudio Streaming Class固有のDescriptorを記述します。TerminalLinkには先程、Input Terminal Descriptorで記述したTerminal ID（0x03）をSetしておく必要があります。データ形式はLPCMであること、L,Rの2ch.のStereoであること、各Ch.あたり16bitなので2バイト必要なことなどを記述しておきます。次に対応しているfs（Sampling周波数）をまとめて記述しておきます。
RAL-2496UT1の場合は44.1kHz、48kHz、88.2kHz、96kHzに対応していますのでそれぞれをHz単位で24bitの2進数に変換して記述します。Hostからのbit数やfsの指定方法については別稿で説明しますが、OSやDriver、ApplicationによってバラバラなのでDevice側としてはそれらすべてに対応しておかなければならず、Descriptorの記述をどうすべきか悩ましいところです。またコントローラによってはRAM（Endpointの数やサイズ）やROMの大きさに制限があるため、あまり大きなサイズのDescriptorは記述することができません。
Audio Streaming Formatに続いて、Endpointに関するDescriptorを記述します。ここではUSBの転送タイプがIsochronousと記述しておく必要があります。またusbviewでは無視されて表示されていませんがIsochronousの転送モードとしてSynchronous、Asynchronous、Adaptiveの3種類のどれに対応しているかということを記述するbit fieldがあります。最近AyerのQB-9の広告などでAsynchronous転送ということが宣伝されていますが、このbit fieldに何を記述してもUSB Audio Data Streamの転送には全く変化はありません。つまり、usbview同様、usbaudio.sysやMacOSのusbaudio Driverなどもこのbit fieldを無視しているのです。AsynchronousをSetしておくと、HostはDevice側が使用するfsを知るためのrequestを発行しなければならないのですが、そういうrequestは発行されません。このあたりの話は後ほどUSB Audio Streamの転送の実際について説明します。
24bit用のInterface Set#2に関するDescriptorがその後に続きます。内容は16bit用と比べてL,R各ch.あたりのバイト数、bit数、パケットの最大サイズが異なるだけで他の部分は同じです。
最後には3番目のInterface（Interface Number #2）としてHID device用のDescriptorを追加してあります。これはRAL-2496UT1固有のコマンドやRequest、FirmwareをUSB経由でupdateするために必要なものです。Audioとは直接関係がありませんので説明は省略します。
次回はこのDescriptorがHostに読み込まれ、USB Audio deviceとして認識され、楽曲の再生が開始されるまでのUSB Bus上でのやりとり、要するにbit数はどのようにしてHostから指定されるのかということについて説明してゆきます。