USB機器が必ず備えていなければならないDevice Descriptorについて前回まででひととおり説明しましたので、それが実際にどのように使われているのかということについて見てゆくことにしましょう。
USBの規格は近日中に3.0に改称されますが、既存のUSB 2.0, 1.1をすべて含むことになっています。したがって、USB Audio機器のほとんどは今年の夏頃からはUSB 3.0準拠 Full Speed対応というのが正確な呼び方になります。
USBに限らず、PC関連の規格は互換性維持のために順守すべき物理的、電気的仕様やプロトコルについて規定しています。したがって、規定されていることすべてに準拠する必要はありませんが互換性維持、PnP実現のためには最低限守らねばならないことが多々あります。規格をはみ出す部分はVendor Uniqueとして対応可能となっていますが、それはあくまでもプロトコルの部分で、物理仕様や電気仕様は必ず守る必要があります。これを守らないとUSB機器が認識されない、データが化けるなどのトラブルを引き起こします。特にUSBケーブルに関して、「オーディオグレードのケーブル」というケーブルが出回り始めていますが電気仕様や物理仕様を順守しているのかがあいまいなので注意が必要です。
USB Audioの伝送が一般のシリアル伝送（RS232Cなどと呼ばれる）やMIDIと全く違うということは図-36-1を見ればおわかりと思います。同図は話を分かりやすくするため、音楽を再生する場合（Isochronous Out）の場合について説明しています。USB Audioの場合は1フレーム期間内（1mS）にPacket（小包）の形でAudio Dataが次々と送られてきます。そのPacket内のデータがUSB Audio Device内部のIsochronous Out Endpointと呼ばれるメモリバッファにどんと配達されます。USB Deviceが受信する場合はInではなくOutです。間違えないようにしてください。
＜図-36-1 USB Audio Streamの転送＞
USB Device内のUSB Audio Stream Contoroller（面倒なので以降はUSBマイコンと呼びます）はSOF（Start of Frame）やIsochronous packet受信完了を検知して、このEndpoint内部のAudio dataを次のFrameが始まるまでに取り出しておかねばなりません。のんびりしていると次のFrameが始まり次のPacketがどんと配達され、上書きされてしまい音楽データが壊れてしまうことになります。要するに宅配Box内部の小包をすぐ取り出しておかないと、次の便の小包を上から押し込まれてつぶされてしまうというわけです。したがって、1mSのFrame期間の間の最初の300μSくらいはIsochronous Packetの受信に費やされてしまいますので残りの期間のうちの500μSくらいの間に取り出しておく必要があります。実際にはDMAでFIFOに転送したり、ピンポンバッファと呼ばれるEndpoint 2個分の大きさのバッファを用意してFrameごとにすり替える方法などがあります。私たちがよく使用しているTAS1020BではCircular Bufferという方式でポインタ（バッファメモリアドレス）を操作して、バッファメモリを帯のようにつなげて一周させるという方法を採用しています。この方法は少ないメモリを有効に活用するためにはいい方法ですが、読み出しポインタが書き込みポインタを追い越してしまわないように気をつける必要があります。
USBマイコンはAudio DataをBufferやFIFOに取り出したあと、Audio DataをI2S（LPCM）に変換して決められた間隔（サンプリング周波数・fs）で正しい順序で送り出さねばなりません。たとえばfsが48kHzの場合には20.8333μS間隔で1mS以内に48組のAudio Dataを送り出す必要があります。USB Audio Stream伝送の最大の難点はこの部分で、1mS間隔でPacketが届き、しかも1mSのうちのどの時点で届くかは決まっていないにもかかわらず、次のFrameまでにこのPacketを取り出しておいて、次のFrame期間内に一定の間隔（fs）で送り出さねばなりません。したがってUSB 規格書の5.12.4.1章で説明されているIsochronousのAsync,Sync,Adaptiveの各Mode bitに関係なく、USB AudioのOut転送はこのルールを守らねばなりません。そして音楽データの順番が狂わないよう、また途中で欠落しないよう各Frame（SOF）とI2SのLRCLKの最初のエッジの同期を取っておく必要があります。
もうすこしわかりやすく説明するために図-36-2を示しておきます。FIFO-Bufferは同図のように大きなタンクと考えることができます。約1mSおきに上部からバケツで水（混じりあわないで順番は守られると考えてください。）がザバッ、ザバッと注入されます。下の取り出し口から一定の速度（fs）で4単位（16bit）もしくは6単位（24bit）一組で順番とおりに途切れることなく取り出しているのと同じことです。48kHzや96kHz、192kHzのように整数の場合はひとつのFrame（1mS）の間に送り出さなければならないAudio Dataの組も整数（割り切れる）なのでまだ問題は少ないのですが、44.1kHzや88.2kHzの場合は割り切れないので難しくなります。以前にも説明しましたが、44.1kHzの場合には44組のDataが入ったPacketが9frame続けて送られた後、45組のDataが入ったFrameがひとつ送られます。要は10mSの間に441組のDataを送り出せるように辻褄を合せているわけです。88.2kHzの場合は88組のFrameが9個と90組のFrameが1個で10mSの間に882組となるようにUSB上に送り出されます。
＜図-36-2 USB上のIsochronous PacketとAudio Data Stream（I2S）の関係＞
Windowsのusbaudio.sysではWindows Meあたりから改良されUSBスタック上に10mS分のAudio Dataを積み上げておくような仕様になっています。44.1kHzの場合は441組のAudio Dataを積み上げておくわけです。それまでは2ないしは3mS分のスタックしかなかったため再生時にブツ、ブツという音がすることがありましたが、10mSとすることにより44.1kHzや88.2kHzのAudioStreamに対応しやすくなり改良されていたわけです。
USB Isochronous Packetで送られてきたAudio Dataは単にメモリ上の連続したbit列でしかありません。これをUSBマイコンがI2S（LPCM）のDataとして整列させるためには各Ch.あたりのbit数と順番をあらかじめ知っておく必要があります。また、fsも知っていなければI2Sデータを作りだすことができません。Network Audioの場合やFlash Memory Audioの場合はWAVファイルやAIFFファイルなどの楽曲ファイルのヘッダ部も一緒にDevice側に送られてきますので、Device側のマイコンはヘッダの情報を読み出してfsやbit数、Ch.数などの情報を得ることができます。また、一般的にはWAVなどの楽曲ファイルとは別にタイトル名、各トラックの曲名、時間（TOC情報）、アーティスト名などを含んだメタファイル（iTunesやMediaPlayerなどアプリケーションによって独自の形式です）やジャケット写真などのjpegファイルもDevice側に転送されてきます。しかし、USB AudioではAudio Dataだけしか転送されませんので、USB Device側のUSBマイコンは他の方法でbit数やfsを知る必要があります。
この方法については次回で。昨年、長期間お休みをさせていただいている間にいただいたYHさん、「えるえむ」さんからのコメントに対する回答は今後の説明のなかで行わせていただきます。