#36 USB Audioについて(その4 実際の転送について)

0 comments

Posted on 22nd 1月 2010 by admin in ものつくりの現場から

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です。間違えないようにしてください。

Z36-1

<図-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上に送り出されます。

Z36-2

<図-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さん、「えるえむ」さんからのコメントに対する回答は今後の説明のなかで行わせていただきます。

#35 番外編 CES2010

0 comments

Posted on 15th 1月 2010 by admin in ものつくりの現場から

 今年もCESに行ってきました。今週一杯はSanta Claraに滞在していますので番外編でCESで見たものの報告をします。いろんなWebで速報版がでていますので、それらに掲載されていなかったものについて触れたいと思います。

 今年のCESはSands Expo(10年前までCOMDEXの際に、私たちがBoothを出していたなつかしい展示場です)、South Hallの1/4、Hiliton展示場の1/3が使用されず、人出は12万人と昨年を7,000人ほど上回ったようですがずいぶんと縮小されていました。狭くなった分、混み合っているような印象を受けましたが主催者の作戦と思います。

 High-Performance Audio(CESでは高級Audioをこのように呼んでいます)の会場もHotelの2フロア+4室、会議フロアの一部に縮小されていました。CESは東京インターナショナルオーディオショウのように一般のオーディオ愛好者に音を聞いてもらうことが目的ではなく世界各地から来るバイヤーに新商品を見せて商談するための展示会ですので、Hotelの一室のベッドを運び出して音を出しています。そして、大声で挨拶や商談をしていますので、とてもじっくりと音を聴けるような雰囲気ではありません。 そういう中で目立ったのは、ほとんどの部屋でNoteBook PC+iTunesでUSB経由のデモを行っていたということです。商談中、CDの掛け替えを気にしなくともよい、いろんなCDを持ち込まなくともよいというメリットがありますが、PCとUSB接続できるDACやDAC内蔵アンプなどが着実に増えていることは間違いありません。また、USB-Bポートだけでなく、USBフラッシュメモリ上の音楽ファイルの再生に対応するためのUSB-AポートやWiFi(LAN)用のアンテナ、EU圏内のDVBに対応した同軸ケーブルコネクタを装備したDACやアンプも目立ちました。どうやらアナログFM放送の時代は終わりつつあるようです。CDプレーヤも何回かRippingして一致するかどうかをCheckしてから、バッファメモリ上のデータを送り出すというような製品が増えています。

 NetWork Audioなどが普及するのを見るのは、草創期からLANに関わってきた一人として嬉しく思いますが、メーカの関係者の多くが著作権保護にまるで無関心なのには心配になります。NAS内の音楽データがNetwork上に漏れ出すと止めようがなくなりますから、そのうちNetwork DACなどを作っているとWinnyの作者のように起訴されたり、Memory Bufferなどを持つDACのメーカが録音保証金を払わなければならなくなるかも知れません。

 著作権が保護されずに作曲家や演奏家、CDなどの制作者が生活に窮するようなことになれば、コンテンツが少なくなり(著作権の切れた50年前の演奏ばかりが残る)、「コンピューター、ソフトなければ、ただの箱」と同様、「DAC、コンテンツなければただの箱」になってしまいます。

(1)dCSのUSB DAC
 DACで有名なUKのdCSもdCSとしては初めてのUSB-DACを発表、デモしていました。24bit/96kHzのUSB Audio Streamにも対応しているとのことです。デモは音源がないとのことでCDを非圧縮AIFFでRippingした16bit/44.1kHzのデータをiTunes を使用してMac Proから送り出していました。他社の製品とちがうところはdCSらしく、外部クロック生成機器と接続し、外部クロックを供給しているところです。パンフレットにはUSB Audio StreamをIsochronous転送のAsyncモードを使って伝送していると記載しており、わざわざ「SRCのAsyncモードと誤解しないこと」と記述しています。ただ説明はUSBの規格書の記述そのままです。本連載で順次説明しますが実際に行われていることとは違いますので、外部クロック(fs)とUSB Streamをどのように同期させているのか興味があります。USB Audioの音質を追求するとこのような形になるのかも知れません。私たちも昨年夏にすでにDACからのfs(LRCLK)入力をS/PDIF出力のMaster Clockとして使用するUSB Transportを作成し、EUのメーカーに組込用に提供しています。

 DAC以降の機器はJeff RolandのアンプとFocalのスピーカーを使って行われており、なかなかいい音でした。ちなみにJeff Roland Gr.の部屋でも同じDAC,Clock発生器を使用してデモが行われていました。

 Model名はDebussy DACですが、まだdCSのHP<www.dcsltd.co.uk>には掲載されていません。USB->S/PDIFコンバータの方のModel名はPUCCINI U-Clockで、こちらからfs Clockを供給していました。Debussy内蔵のClockが信用できれば必要ないと思えるのですが。あまり写りがよくありませんが写真-35-1,2を参照してください。

P35-1 
<写真-35-1>一番上の段がDebussy DAC、3段目がPUCCINI U-Clock

P35-2
<写真-35-2> dCS Debussy DAC

(2)PS AudioのuPnP対応DAC(USB入力もあります)
 PS Audioの部屋ではuPnPを使用して、iPod TouchやiPhoneですべてをコントロールするDAC(Model名は PS PerfectWave DAC)のデモを行っていました。iPhoneをuPnP対応コントローラとして使用する機器で有名なものはLinn DSシリーズですが、PS Audioの製品は選曲、演奏開始、停止だけでなくDACの入力切り替えやその他の機能設定などすべて行うことができます。PCとLANで接続した状態でiPhoneからコントロールを行うためには、PCがDLNAサーバとして機能することが必要ですがWindows7の標準機能として組み込まれていますので問題はないようです。したがって、LANポートが必須ですが、PerfectWave DACではOptionでLANポートを組み込むようになっています。Network Optionなしの場合は一般的な赤外線リモコンを使用しますが、こちらはあまりおもしろくありませんでした。Digital入力はDLNA対応Network(24/192対応)、USB(24/96対応)、AES,COAX、Toslink,HDMI(ただしコネクタのみHDMIでPS Perfect Transport専用I2S入力)です。こちらは<www.psaudio.com>に掲載されていますので参照してください。

(3)MagicoのHardDisk Tranport?
 テクニカルブレインの黒沢社長と会場で出会い、「別の階(35階)でアンプのデモを行っているからおいでよ」と誘われてMagicoの部屋にいってみました。新製品の高級スピーカーをテクニカルブレインのプリアンプ+パワーアンプ4台でバイアンプ駆動していました。音源は2track/38cmのオープンリールのテープデッキとUS$60,000というハードディスクDAC(?)でした。大きさは大型のPCケースと同じで詳しい内容は不明でしたが、とにかくCD直接ではなく、HDD上にRippingしたものを再生しているというのが驚きでした。MagicoのHPにはSpeaker Systemしか掲載されいませんので、どこかの製品と思いますがUS$60,000という価格にも驚きました。

(4)ついでに
 私たちの製品、Super Speed USB(USB 3.0)対応のHostAdapter 2種類CES直前にLogo認証Testに合格し、CESのUSB Tech Zone NEC Bothで展示・デモが行われました。Logo認証Testの合格は国内ベンダでは今のところ私たちだけです。USB 3.0やUSB 2.0というのは規格名を表すというように改訂され、それぞれが下位の規格(数字が小さいもの)を含むというようになりましたので、USB 2.0対応のUSB DACと称していてもほとんどの製品が旧USB 1.0のFull Speed(12Mbps)で動作していますので惑わされないようにしてください。

 Audio Stream(LPCM)を対象とする場合はFull SpeedではIsochronous転送に従う限り24bit/96kHzが最高です。24bit/192kHzをIsochronous転送で扱うためにはHigh Speed(480Mbps)が必要となります。Boothの写真は写真-35-3,4です。

P35-3
<写真-35-3>左上のパッケージ2個が弊社HostAdapter

P35-4
<写真-35-4>右側2製品が弊社HostAdapter

 寄り道はこれくらいにしておきます。USB Audioはアマチュアでも自作できそうなので真空管アンプつくりの次の楽しみとして浮上しそうです。しかもdigitalのいいところ(誰がつくっても差がない)でEUの歴史あるメーカーが発表しているUSB DACであればそう難しくはありませんし、F/W、H/Wを正しく作れば音質面でもいい勝負ができます。Network AudioはDLNAなどライセンスが絡んでいますのでアマチュアでは手を出しにくいという問題があります。USB Audioで自作の楽しみを取り返しましょう。

 それでは、このへんで。

#34 USB Audioについて (その3 Device Descriptor編 #2)

0 comments

Posted on 8th 1月 2010 by admin in ものつくりの現場から

 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の分解能を指定するためにも使用されますので、この部分は非常に大切です。

 (1)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しておくのが一般的です。

H34_1 
<表-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準拠ということになります。

H34_2

<表-34-2>Audio Class-Specific AC Interface Descriptor Subtypes

 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は使う方はとても便利ですが、つくる方は大変なのです。

D34_1 
<図-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です。

(2)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から指定されるのかということについて説明してゆきます。