ラトックシステム PC オーディオ ブログ

#39 USB Audioについて（その7 補足....Jitterの話の前に。）

　USB Audioもあちこちで取り上げられるようになり、クロックやケーブルに関する議論が盛り上がっています。しかしながら、クロックに関しては前回までの当Blogで説明したようにほとんどが間違った思い込みで語られています。とりわけPC側（音楽データの送り出し側）に関する誤解・珍説が多く「PCのクロックの精度が影響する」というような説が流布されています。同じようにJitterに関しても「Jitterの実体」を見たこともないまま「ジッタ、ジッタ」と騒いでいます。この連載ではJitterの実体と実態を示しながらどこで発生する（大きくなる）のか、対策は何なのかということについて説明したいと思います。ただし、「Jitterが少ないから音がいい」と言っているのは「ジッタ、ジッタ」と騒いでいる人達です。私たちはそう結論づけているわけではありませんが原音再生にはJitterが少ない方がよいと考えています。

　Jitterの話を進める前に再度USB Audioパケットの伝送についておさらいをしておきましょう。#37にYHさんからコメント（ご質問）をいただいていますので回答を兼ねて説明したいと思います。これまでの図版をもう一度参照しながら読み進めてください。

　これまで説明したように再生するためのAudio Dataは録音あるいはRippingされてdataとして記録された時点でサンプリングクロックとは直接的な関係がなくなります。どれだけのSampling RateでA/D変換されたのか、すなわち一組のデータはどういう時間軸（Sampling Rate）で採取されたのかという属性情報によって意味づけされるバイナリデータ（'0'と'1'の列）として扱われます。これがUSBという伝送路を通してUSB-DACなどに送り込まれます。

　USBはデータ伝送のためのしくみですので、ベルトコンベアや鉄道のようなものと考えることができます。usbaudio.sysで使用されるFull Speed（12Mbps）のIsochronous転送は、ちょうど1mS（1フレーム間隔）おきに定時発車する電車に決まった数の乗客を乗せて運んでいるようなものです。列車は定時運行と速度維持のために完全に独立した計時機構（USBクロック）を持っています。このクロックもAudio StreamのClockとは直接関係がありません。

　PC側のSoftware,Hardwareが関与するのは、Storage Device（HDDやSSD,USB Flash memoryあるいは SD CardなどのFlash Memory）から主記憶（RAM）上に音楽データを読み出すこと、読み出したデータを属性情報に従ってUSBスタックに積み上げることだけです。属性情報にはA/D変換された際のSampling RateやCh.数（Stereoかmonoralか）、Ch.あたりの解像度（bit数）にもとずくバイト数（16bit/Ch.なら2Bytes,24bit/Ch.なら3Bytes）が含まれていますので、PC側のSoftwareは1mSの間にAudio Streamとして転送される（D/A変換される）べきバイト数のデータを揃え、10mS分をUSBスタックに積み上げてusbaudio.sys（WindowsPCの場合）に渡します。usbaudio.sysはこれをUSBの計時機構（クロック）にしたがって、USB-DACなどのUSB Audio Deviceに送りつけます。したがって、PCのクロックはRAMやDeviceからの読み出し、バスマスタ転送、DMA転送などでは使用されますが、それによって読みだされる楽曲データが影響されることはありません（データ化けをすればError訂正されます）し、元のA/D変換時のサンプリング情報が変わってしまうようなことはありません。PC側でA/D変換時のようにPCのクロックを使用して44.1kHzや96kHzでサンプリングを行って楽曲データを読み出し、USBバス上に送り出しているわけではありません。間違えないでください。

　USB Audio Device側では1mSごとにSOF（Start of Frame）検出割り込みが発生します。SOF割り込みは新しいフレームの始まりの検出と同時にひとつ前のフレームの受信完了を意味しますので、SOF割り込みが上がってきた時点ではEndpointにひとつ前のフレームで受信したIsochronous Outパケットで運ばれてきたデータが入っています。RAL-2496UT1で採用したTAS1020Bでは、あらかじめ1組のSammpling RateあたりのByte数を設定しておくと、何組のデータを受信したかを通知してくれます。そこでRAL-2496UT1内部のFirmwareがこの通知を受け取って44/45あるいは88/89が続いていればAudioのベースクロックを22.5792MHzに、48あるいは96が続いていれば24.576MHzに設定します。もし、これら以外の数が通知されれば、例えばUSB通信上で発生したErrorでデータが落っこちた場合や、全く入っていなかった場合などにはそれまで使用していたベースクロックをそのまま使用します。したがって、YHさんからのご質問にあるような43組のサンプリングデータが間違って送られてきたような場合でも、RAL-2496UT1の場合にはそれまで使用していたベースクロックを維持しますのでDACへ送り込むLRCLK（Sampling Clock）が狂ってしまうことはありません。また、初期設定として16bit/44.1kHzモードに設定していますので、bit数の情報がこなかった場合や変な数のIsochronousパケットが続いた場合でも狂ってしまうことはありません。

　ただし、Audio用のベースクロックをFirmwareで設定するのではなく、Wired Logic（Hardware）でPLLを設定することによって作り出している場合は方法によっては変な数が来ると狂うことがあるかも知れませんが、実際に実験を行って確かめたわけではありません。

　また、上記のように元々USB AudioはASYNC（送信側にClockがなく、受信側が独立したClockを持っている）ですので、YHさんの2番目のご質問のように何らかの方法で送信側がSetする1mS以内にD/A変換すべきデータの数と受信側が生成するSampling Clockを一致させ、Startを同期させないとバッファのオーバーフロー、アンダーフローが発生しやすくなります。

　まずオーバーフローですが、オーバーフローが発生するのは一つ前のフレームで受信したデータを次のフレームの受信が終わる（次のSOFを検出するまでに）までAudio Streamとして転送しきれなかった場合に発生します。#37でも説明しましたが、Audio Stream作成時にはひとつ前のフレームで受信したデータを一定の間隔で送り出さなければなりません。しかし、次のフレームのパケットがEnd Pointにドサッと一気に書き込まれますので、一つ前に受信したデータが上書きされてしまう可能性があります。これを避けるためにEnd pointを複数個用意しておいて次々に切り替えてゆく方法や、リング状のバッファを用意しておいてハツカネズミの車のようにくるくると回す方法があります。TAS1020Bでは少ないRAMを有効に活用するため後者の方法を採用しています。したがって、回転（Sampling Clockによる読み出し）さえ止まらなければバッファがオーバーフローすることはありません。しかし、輪の直径が小さい（円周が短い）と読み出し位置が書き込み位置に追いつかれたり、追い抜かれてしまうとオーバーフローが発生しています。これを回避するためには輪の直径をうまく決めておかねばなりません。そこがFirmwareの勘所です。

　SOF－SOF間隔が1mSちょうどで、LRCLK（Audio StreamのSampling Rate）も正しければこの状態で問題が発生することはありませんが、Audio Streamを作成するために音楽（曲）の始まりとLRCLKの最初のL-Ch.のエッジを同期させてStartさせる必要があります。そのため、SOFとSampling ClockのStartは少しずれることになります。このズレが一定であれば問題は生じませんが、ズレが大きくなると次のSOFが来てもまだバッファ内にAudio Streamとして未転送のデータが残っている場合があります。この場合も、この残りの処理をうまく行わないとLRがひっくり返ったりします。

　アンダーフローはパケット内部のデータが足りない、あるいはパケットが届かなかったという場合に発生します。この場合、バッファ内部に残っている以前のデータをそのまま使用してAudio Streamを作成し続けるか、ゼロデータ（無音）を出し続けるか、Audio Streamを止めるかというどれかを選択しなければなりません。Audio Data（LRCLK,BCLK）を止めると後段のDACなどがリセットされる場合があるので一般的にはゼロデータを送り出します。そうすると前後の音によっては「バチッ」という音になってしまいます。これに関してはPC側を何とかしないと、Device側では「なるべく人の耳に聞こえにくくする」というゴマカシの対策しか今のところはありません。TAS1020BなどのUSBコントローラにはSOFを検出してから1mSを過ぎても次のSOFを検出できなかった場合、偽のSOF検出割り込み（PSOF）を発生させる機能もあります。しかし、現実にはPSOF割り込みは上がってきたことがありません。

　USB経由でAudioデータを受信し、Audio Streamを生成するしくみについて理解していただけましたか？Jitterの話に進む前にこのしくみと「PCのクロックの精度がUSB-DACのD/A変換用のクロックに影響する」という説は正しくないということを理解しておいてください。

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

#37 USB Audioについて（その5 bit数とSampling Rateはどのようにして決められるか）

　前回の図-36-1を理解していただけましたか？　同図のようにUSB信号線上はUSBの転送レート（この場合は12Mbps）によるPacket転送であり、USB Audio DataそのものはPacketの中の単なるバイナリデータとして扱われます。データはUSBの転送ルールにしたがってIsochronous転送されますので、USB-Host（PC）やUSB Audio Deviceのコネクタ部や基板パターン、PHY（Chipの物理層）周辺、ケーブルなどのどちらかといえばアナログ部の影響を受けます。何らかの問題がある場合はデータの不一致や誤認識、欠落が発生します。これが発生しないようにクリアすべき電気的な基準がUSB規格で規定されています。

　Full Speed（12Mbps）も低速とは言え高速シリアル転送ですのでジッタに関する規定もあり、測定時には一目で判定できるようにアイパターンが規定されています。これまでの私たちの経験では、USB Audio機器が正しく認識されないようなケーブルや、データ転送の途中で転送を止めてしまうようなケーブルはこのアイパターンテストで不合格となります。

　USBの転送時に使用されるClockは両側のUSBコントローラの発振回路（TAS1020Bでは6MHｚの水晶を使用し、内部のPLL回路でFull Speed転送に必要な48MHzを作成しています。）でつくられていますが、Audio DataがIsochronous Packetとして転送される場合、受信側は送信側のSpeedに合わせるため、PLL回路を動作させて送信側のClockに追従してLockさせたClockを使用します。したがって、前回の図-36-1からもおわかりのようにPCからのUSB Clockおよび受信側のUSB ClockはAudio DataをI2Sに変換するためのAudio Clockとは全く別のClockです。Host（PC）から送り出されてくるUSB DataからS/PDIFのようにAudio用のClockを作成しているわけではありません。ましてやPCのClockがアプリケーションソフトウェアの動作により影響されてゆらいだままノイズを載せてUSB Audio機器に入り込んでくるということはありません。iTunesでCover Flowなどを動作させるとUSB Audio接続のAudio機器~ブツブツ音が聞こえるというのは別の原因です。

　PCとUSB Audio機器双方のUSBコントローラ相互間はSYNCモードですが、PC側と機器側のAudio Clock（LRCLK,MCLK）は完全に独立したClockを使用しますので一般的な定義ではASYNCということになります。しかし、サンプリング周波数と位相（LRCLK）、各Ch.のbit数が一致しないと音楽の始まりやつながり、テンポや音程が無茶苦茶になってしまいます。MIDIの場合は音符のコードや小節ごとの同期コードなどが決められていましたがUSB Audioの場合はそんなものは何もなく、いきなりバイナリ（'0'と'1'の組み合わせ）データが送られてきます。したがって、単なるASYNCではStart bitもStop bitもありませんのでどこが曲の始まりか、どちらがL.Ch.のデータかR.Ch.のデータかわからなくなってしまいますので送り出し側（PC）と受信側（USB Audio機器）の間でSoftware（プロトコル）レベルで同期をとることが必要です。

　図-37-1を参照してください。前回の図-36-1ではfs（LRCLK）が48kHzで1mSのUSB Frame間に整数個のデータがきちんと収まる場合を図示していますが、図-37-1ではCDを非圧縮でRippingした44.1kHzのデータの場合を図示しています。CDがUSBよりも10年も前に普及し、音楽ソースとして無視できない存在ですのでUSB Audioの規格を決めた人達もずいぶん苦労されたようですが、この44.1kHzや88.2,176.4kHzというfs（1msで割り切れない）にはずいぶん苦労させられます。これまでも何度かお話しましたが、44.1kHzの場合、USB Audio Driverの10mS分のスタック上に1パケットあたり44サンプル分のデータが9パケット分と45サンプル分のデータが1パケット分積み上げられ、順番にUSB Bus上に送り出されます。

＜図-37-1＞fs=44.1kHzの場合

　以下は図-37-1を参照しながら読み進めてください。

　まず最初のPacketの受信が終了し、次のFrameのSOFが検出されると最初の44組のデータをI2Sに変換しなければなりません。ただし、LRCLKは44.1kHzですので次のSOHまでの1mSまでの期間に2.27μS（1.0mS - 1/44.1k x 44 ）の隙間（GAP）ができてしまいます。音楽の途中でこんなGAPがあると音が狂ってしまったり、バチッというLPレコードの引っかき傷のような音が出てしまいます。そのため、次のパケットの先頭一組を取りだしてきてくっつけます。2番目のパケット内のデータを送り終わった後では4.54μS、3番目のパケット内のデータを送り終わった後では6.81μS...とだんだんGapが大きくなり、9番目のパケット内のデータを送り終わった後には20.43μSとなります。この時点で10番目のパケットの最初の組をくっつければ10番目を転送した直後は11番目（最初のFrameは転送しないので）のSOHに一致します。したがって、USB Audio機器側でもPacket10個分（10mS分）のバッファメモリを用意すればSoftwareやHardwareが簡単になりますが、16bit/44.1kHzで1,764バイト（4x441）、24bit/96kHzにも備えておくとすると5,760バイト（6x960）のRAMが必要となります。現時点で入手可能なUSB Audio StreamコントローラのTAS1020Bを例に取るとEndpointやBufferとして使えるRAMは最大で1304バイト程度ですので10mS分のバッファは用意できません。TAS1020Bではひとつながりのリング状にバッファを設定することに（Circular Buffaer）よって、この44.1kHzベースのAudio dataに対応しています。

  パケット内のデータを取り出しI2S（LPCM） Streamに変換するためには各Ch.（L,R）のbit数、fsに関する情報が必要です。USB DACやUSBトランスポートなどのIsochronous Out転送の場合、これらのパラメータを決定する主導権はPC上のSoftware（iTunes/QuickTime PlayerやMedia Player,KernelMixerなど）にあります。また、実際に使用する上でも、楽曲ファイルのフォーマットに従って転送が行われ、USB Audio機器側では何の操作する必要がないほうが最も使いやすいと思います。たとえば16bit/44.1kHzでRippingされた楽曲ファイルを選択すればUSB Audio機器やAudio機器側で何も操作せずとも16bit/44.1kHzで再生され、24bit/96kHzでRippingされた楽曲ファイルを選択すれば同様に24bit/96kHzで転送されて再生されるという具合です。

　Isochronousの転送モードがASYNCであるか、SYNCかAdaptiveであるのかに関係なくUSB AudioではHost側（PC）がUSB Audio Deviceから取得したDevice Descriptorを解析し、その機器が24bitにも対応しているのか、それとも16bitだけにしか対応していないのかInterface descriptorを元に判断します。そして、Audio Data Streamに関するInterface Setごとに、ReadyかどうかをRequestを出してUSB Audio機器側に問い合わせます。

　本Blogの#33-図-2に示すRAL-2496UT1の例ではInterface Set#1が16bit用、Interface set#2が24bit用として記述されていますので、PCからSet#2はReadyかどうか、Set#1はReadeyかどうかというRequestが発信されてきます。USB Audio機器（RAL-2496UT1）側ではこの時点ではPCからどんなフォーマットのAudio Data Streamが送られてくるのかということが不明ですので、とりあえず、すべてのRequestに対してReadyを返しておきます。

　PC側でiTunesやMediaPlayer,fooberなどのアプリケーションを起動するとQuickTime Player, Control panel, アプリケーション自体の設定に基づいて、bit数を指定するためのSet InterfaceRequestがUSB Audio機器に送られます。このRequestに対してUSB Audio機器がReadyを返せば、その時点でそれ以降のAudio Data Stream転送で使用されるbit数が決定されることになるわけです。RAL-2496UT1の場合は図-37-2のように音楽データ（Isochronous）に先立って、Set Interfaceが送られて来ます。ただし、bit数が既知（ひとつ前の楽曲再生と同じ場合はSet Interface Requestは発行されませんので、USB Audio機器側は同じbit数のモードを維持し続けなければなりません。次に再生する楽曲のbit数が変更される場合は前述のようにそのbit数に対応したSet InterfaceがHost（PC）から発行されます。図-37-2の場合は24bitのAudio Data Streamを送るということをPCからRAL-2496UT1に通知していることを示しています。

Packet 5102 がSET_INTERFACE Request で Alternative Setting#2（02, Ch.あたり24bit）を指定しています。

＜図-37-2 USB Host（PC）からUSB Audio Device に対するbit 数の指定＞

　サンプリング周波数（fs）の指定に関しても同様にHost（PC）はInterface Descriptorを参照します。#33-図-2のRAL-2496UT1の場合は16bit、24bitそれぞれのbit数で44.1,48,88.2,96kHzの4種類に対応していると記述していますのでPCはiTunesやMediaPlayerなどの指定にしたがって、どれかのサンプリング周波数に基づいてファイルから読み出したAudio Dataを{（bit数/8） x （fs/1000）}バイトずつ一つのパケットに詰め込みます。例えば24bit/96kHzの場合は（6 x 96）バイトを一つのパケット（1mS分）に詰め込むことになります。

　その後、Audio Dataが詰め込まれたパケットを10個ずつusbaudio.sysに渡して転送実行を命令します。これらのパケットがぞろぞろとUSB bus上を一列縦隊行進しながらUSB Audio機器にやってきます。ところがUSB Audio機器側には、bit数の時のように届く予定のAudio Dataに関してあらかじめfsに関する情報は何も通知されていません。したがって、USB Audio機器側では届いたPacket内のAudio Dataのバイト数からfsを算出しなければなりません。各Ch.のbit数はあらかじめわかっていますからバイト数を6（24bit）もしくは4（16bit）で割り、その商に1,000を掛けるとfsが得られます。前述のようにfsが44.1kHzの場合には商が44であったり45であったりしますが、それはF/Wでfs=44.1kHzと処理することにすればOKです。88.2kHzの場合には88組のパケット4個に続いて89組のパケットが1個という順番で送られてきますので商が88か89だったらfs=88.2kHzと処理することになります。

　Isochronous転送でモードがASYNCの場合にはプロトコルの規格上はDevice側で使用するfsを問い合わせるRequestとそれに対する応答用のEndpointがやり取りされることになっていますが、現実にはそんな面倒なことは行われていません。また、規格上はパケット内のバイト数をCheckしてfsを割り出すのはAdaptiveモードですが、Isochronous Out EndpointのMode bit（ASYNC、SYNC,AdaptiveのModeセット用）をいくら換えてもHost側の挙動には変化がありません。USB Audio機器側がfsを検出するためには、Host（PC）側はパケットサイズによって通知するしかありません。

　Deveice DescriptorのInterface Setの記述方法を一つのbit数/fsごとに記述する方法によりSet Interface requestでbit数/fsを選択する方法もありますが、KernelMixerなどが、機器が対応している最高の組み合わせに内部で勝手にサンプリングレート変換を行ってしまうという問題があります。また、USBマイコン側の問題としてはDevice Descriptor用にそんなに大きなEndpointを用意できないという問題もあり難しいところです。また、QuickTimeやFooberなども指定したbit数が常に使用されてしまうという問題がありますので、この記述方法は最近ではあまり使用されていません。　ただし、独自のfs、bit数設定用のApplicationをあらかじめインストールするタイプのUSB DACなどはこの方法を採用していますが、独自のアプリケーションやドライバをインストールしなければならないこと、OSやiTunes、MediaPlayerなどのVersionが変わるたびにそれらに対応した新しいドライバやアプリケーションが必要になるという問題などがあります。　また、FOSTEX HP-A3のように16/96kHzと24/96kHzにのみ対応と記述されたDevice Descriptorを持つUSB Audio機器の場合、KernelMixerなどがDescriptorに基づいてUSB Audio出力のfsをすべて96kHzにサンプルレート変換して送り出します。たとえば16/44.1kHzでRippingされた音楽ファイルを再生する際にはPC側のSoftwareでサンプルレート変換が行われます。この場合もfsの指定などのRequestはPCからは発行されず、すべてのIsochronousパケットのサイズ(バイト数)が576または384となるだけです。

　USB Audioでbit数やサンプリング周波数が決められている方法はこのようなシンプルな方法です。プロトコルの規格上はいろいろと面倒なことが記載されていますが、USB DACやUSBヘッドホン、USBスピーカーなどのIsochronous Out専用の場合はこのような簡単な方法が採用されています。

　「USB Audioでのサンプルレートの指定方法」について昨年10月にYHさんからコメントをいただいておりますので回答させて頂きます。

　ご質問の件は上記のように「パケット内のバイト数により指定されている」というのが現実です。USB Audioの規格書では「implicitな指定」と記述されています。また同じコメントで「データパケットの間隔をPLLで逓倍してDACのClock（I2SのLRCLKやMCLK）を作成している。」と記述されている他のblogに関しても言及されていましたが、これはYHさんのおっしゃるとおり正しくありません。DAC用のClockはPC側のクロックとは全く関係なくUSB機器側で作成します。USBで必要な48MHｚや12MHzなど内部のマイコンの動作クロックの作成に使用される6MHz水晶発振子を共通に使用して周波数シンセサイザで24.576MHzや22.5792MHzを作成しています。あるいは別に搭載されているAudio専用の水晶発振回路でそれらの周波数のClockを作成しているかのどちらかです。どちらを選ぶかはそれらのMCLKそのものやMCLKから作成されたfs（LRCLK）のJitterが少ない方ということを基準にすればよいと思います。前回の#36でも説明しましたがUSBのSOFの間隔（Frame間隔・1ms）は一定ですが、パケットとパケットの間隔は一定ではありません。したがって、YHさんのご意見が正しいということになります。

　「バイナリデータの不一致」に関して「えるえむ」さんからも昨年12月にコメントをいただいております。今回の記事をお読みいただければおわかりのように、ファイルから読み出したバッファメモリ上の音楽データは、当然HDDなどに記録されたものと「バイナリ一致」が保証されていますが、usbaudio.sysへの10ms分・10個のパケットの引き渡し以降は一切、Errorチェックも訂正もありません。Isochronous Dataが壊れているというErrorは通知されますが再送要求などはありません。また、Isochronousデータは受信が終わって初めてサイズがわかるという代物です。なぜ、Errorチェックや再送要求があるBulk転送が使用されないのかということは別稿で説明します。

　USB Audio Streamの転送についてはこれくらいにして次回はJitterについて実測結果などをもとにお話を続けたいと思います。

#36 USB Audioについて（その4 実際の転送について）

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

#35 番外編 CES2010

　今年も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、コンテンツなければただの箱」になってしまいます。

（１）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を参照してください。

 
＜写真-35-1＞一番上の段がDebussy DAC、3段目がPUCCINI U-Clock

＜写真-35-2＞ dCS Debussy DAC

（２）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>に掲載されていますので参照してください。

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

（４）ついでに
　私たちの製品、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です。

＜写真-35-3＞左上のパッケージ2個が弊社HostAdapter

＜写真-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）

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

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

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

#33 USB Audioについて （その2 Device Descriptor編 #1）

　USBは簡単に1本のケーブル（USBメモリーのようにケーブル不要のものもありますが）でいろんな機器を接続するだけですぐ使える状態になるということを目標に規格化されました。USB1.0として公表される前は、MicrosoftのWinHECやintelのIDF、PCIのDeveloper会議などで提唱者のPapertさんがセントロニクスのプリンタケーブル、RS232Cのケーブル、SCSIケーブルなどの束をお坊さんの七條袈裟のように身に纏い、右手には1本のUSBケーブルを持って、「これらすべてのパラレルケーブルがこれ一本になる!」とプレゼンしていました。その時はUSBオーディオなどとは思いもよりませんでした。またAudio Video関係は放送局や録音スタジオ用などを含めてIEEE1394（i-Link）が優勢でしたので、AV分野ではIEEE1394が勝つものと思っていました。たしか当時はMIDI（ASYNCシリアル）をUSB上に移植しようというのがUSB オーディオの始まりだったと記憶しています。

　その後、1998年にUSB Device Class Definition for Audio Device 1.0, USB Device Class Definition for Audio Dataformat 1.0, USB Device Class Definition for Audio Terminal Type 1.0が制定され、現在私たちが使っているUSBオーディオの基本形が出来上がりました。これらの規格は2006年5月にそれぞれ2.0に更新されていますが、DolbyやDTS,MP3,AACなど圧縮フォーマットの取り扱いやMulti ChannelのLPCMなどの取り扱いが追加されているだけです。私たちが対象としているLPCM-2ch.に関してはRev.1.0から何も変更されていません。Terminal typeでは1.0の頃からUSB Transport用にS/PDIF outputという種別がありましたので、この種別コードを使用したUSBデバイスをWindowsに接続するとS/PDIFというアイコンが表示されます。

  USBポートに何らかのUSB機器を接続すると、OS（WindowsやMacOS、Linuxなど）がUSB機器に対してDevice Descriptorと呼ぶ機器固有の情報を提供するように要求します。その後、その情報を解析しOS内部に登録します。この一連の操作がEnumerationとかConfigurationと呼ばれ、Registryと呼ばれる内部領域に登録されます。このへんがUSB機器にとっての第一関門です。さらにOSはそれぞれのUSB機器に対応したDevice Driverをロードします。ロードする際にはRegistryや*.infと呼ばれる特別な情報ファイルを参照します。USBオーディオ機器の場合はusbaudio.sys（Windowsの場合）というDriverがロードされなければなりません。ここまで到達してはじめてWindowsではデバイスマネージャのデバイス（種類別）表示でUSBコントローラーの下にUSB複合デバイスとして、さらにサウンド、ビデオ、およびゲームコントローラーの下にUSBオーディオデバイス（Windows7、VistaではUSB機器のDevice Descriptorに記述されているモデル名）が黄色の!マークや赤のX印なしで表示されるようになります。ここまで到達するためにはUSB機器側ではOSが発行するRequestに対して応答しなければならないだけではなく、上記の3種の規格書で定義されているDeveice Descriptorの個々の内容に従って間違いなく記述されたDeveice Descriptorを返送しなければなりません。みなさん方は自分でDescriptorを記述することはまずありませんのでこれらの文書は必要はありませんが興味のある方はwww.usb.orgからzipファイルの形でdownloadできますので参照してみてください。TIのPCM2704などを使用してUSB DACを自作される場合はVendor名やModel名などが書き換え可能領域としてユーザーに開放されていますのでこれらの文書を参照されるのもよいと思います。

　実際のUSB機器内部のDevice Descriptorを読みだして表示させるユーティリティがMicrosoftから提供されています。本来はWindows DDK（Device Driver Development Kit）に含まれていてMSDNからfreeでdownloadできたのですが今は見当たりません。しかし、usbview.exeで検索するとdownload可能なサイトを見つけることができます。図-1のようにピンクに色が変わっている機器がEnumerationとCondigurationが完了している機器を示します。各機器の詳細な情報を表示させるためにはOptionsタブのConfig Descriptorにチェックマークを付けてFileのRefleshをクリックしてください。図-2は実際にRAL-2496UT1のDevice Descriptorを読みだしたものです。Device Descriptorから読みだされた情報、特にInterface Descriptorはusbaudio.sysやMediaplayer, Quicktime Player, Mixerなどでも参照され、USBから送り出すオーディオデータのサンプリング周波数やbit数が決定されます。

＜図-1＞usbview の EnumerationとCondigurationが完了している機器

＜図-2＞USB Audio Device の Device Descriptor例（RAL-2496UT1）

　したがって、Deviece Descriptorを見るとそのUSBオーディオ機器が持つ能力をすべて知ることができます。

　Device Descriptorは図-2の左側のコメントに示すようなブロックに分かれています。2番目のConnection StatusはDescriptorに記述されているものではなくusbviewが現在の接続状況を表示するために付け足したものです。先頭のDevice Descriptor部はUSB機器すべてに共通でオーディオ機器であろうがHDDであろうがキーボードやマウスでも同じ書式です。idVendor欄のVendor CodeはUSB I/Fによって割り当てられたベンダコードで私たちの会社は1412なので16進の0x0584が記述されています。その次のidProductは私たちが割り当て、USB I/Fに登録します。その下には製造者名、型番などが記述されている場所へのindexが記述されていますのでusbviewが読みだして表示しています。これらの製造者名や型番はWindowsではコントロールパネルやデバイスマネージャで表示されます。上記のようにPCM2704ではこの部分は書き換えることができますので、PCM2704を購入して自分でUSB DACを作られる方は100円くらいの256ByteのSEEPROMを追加して挑戦してみて下さい。USBオーディオデバイスとしてmy nameが表示されるのも楽しいものです。

　その次のControl転送、interupt転送用のEndpoint Descriptor 2個（入出力用）はResetなどのCommandやStatusの受け渡しのためにUSB機器が必ず備えていなければならないものです。Configuretaion descriptorも同様で、ここではBus_Poweredという記述子と消費電流の記述子に注目しておいてください。

　それに続いていよいよUSB Audio固有のInterface Descriptorが登場しますが、説明は次回以降で..

#32 USB Audioについて （その1）

　2月25日以来、約300日近くお休みをいただきました。HDMIを忘れてしまった訳ではありませんが、今回から今が旬（?）のUSBオーディオについていろいろ記載してゆきたいと思います。休ませていただいている間に（10月の半ば頃）USB オーディオに関するご質問をYHさんからいただいていますので、この連載のなかで紹介、回答させていただきたいと思います。

　私たちが細々と続けていたPCオーディオも最近はオーディオ誌が特集を組んだりするようになり、パソコンユーザーだけではなくオーディオマニアの人たちからも注目されるようになりました。24bit/96kHzや24bit/88kHzの高サンプリングレートの音楽ソースが簡単に入手できるようになり、それらを再生するためにPCオーディオやネットワークオーディオを使用しなければならなくなったという背景もあると思われます。
　
　PCオーディオの場合、パソコンで管理している音楽をもっとも簡単に取りだす方法がUSBオーディオであるということは事実です。特別なデバイスドライバーなどをインストールする必要もなく、LANの設定などを行わなくともUSB DACやトランスポートを接続するだけで音が出せますのでパソコンに詳しくない人達でも簡単に使用できるという便利さがあります。ただし、現時点ではUSBから24bit/96kHzなどの高サンプリングレートの音楽を出力させるためにはMedia PlayerやQuickTime Playerなどで24bit/96kHzや24bit/88.2kHzを扱えるように設定する必要がありますが、LANの設定に比べれば簡単で間違えてもLAN全体やWebブラウザなどに影響を与える恐れはありません。ネットワークオーディオの場合はLANの設定が必要なのと、外出時でもサーバーの音楽が取り出せるというのは著作権保護の観点からとても危険です。Winnyなどで簡単に音楽ファイルが取りだされてしまう恐れもあります。USBオーディオでもパソコンにネット経由で侵入されれば同じことですので、外部侵入に対するセキュリティ対策には気をつけておくべきと思います。DRM（デジタル著作権保護）の有無に関係なく、音楽CDをリッピングして作成したファイルの取り扱いに注意するのがPCオーディオを楽しむ上での最低限のマナーだと思います。

　USBオーディオが一般的になってくるのはUSBの開発に15年以上（USB1.0として公開される前から）かかわって来た身としては嬉しいことですが、霊感商法や催眠商法と紙一重のケーブル商売や制振グッズ商売などがUSBオーディオの周囲にも登場し、しかももっともらしい理論付けをしているのを目の当たりにするのは、あまり嬉しくありません。また、USBやパソコン関連と言うだけで「どうせパソコン屋が雑に中国あたりで作ったものだ」と軽蔑する人達もいます。確かにUSBインターフェイスなどは、時間と労力、開発費用をかけて開発して世に出しても、半年もすれば設計データをタダで入手し基板を中国で作って販売する会社が現れ、価格が1/5から1/10になってしまいます。時間と労力、費用をつぎ込んで開発している身としては、そのような商品が出回ることに対してやりきれませんが、パソコン関連メーカーのUSB製品すべてがそうではないということは認識していただかないと困ります。

　USB DACとしてよく採用されているPCM2704も10年くらい前に日本バーブラウンの人達の努力によって開発されたものです。当時私たちの会社はUSB2.0のホストアダプター（CardBusカードやPCIボード）を開発・販売していましたので、USAで年に4回開催されるUSB Compliance Work Shopと呼ばれる催しにSuite（試験室）を持っていました。そこにはいろいろなUSB機器を開発している人達が開発中の製品や試作品を持ってやってきます。そこで私たちのホストアダプターと接続して正しく設計どおりに機器やデバイスドライバーが動作するかということをお互いにMicrosoftやintel、Appleなどのエンジニアを交えて確認を行います。PCM2704の場合、日本バーブラウンの人がいつも日本から出張されてきて、相互接続試験や互換性試験のために私たちのSuite（試験室）に来られていました。その人達の努力のお陰でPCM2704が商品化されパソコンやUSBの仕組み、ソフトウェアやハードウェアについて何も知らなくともデータシートに記載されているとおりに、いくつかの受動部品（CR）を接続してUSBポートに接続すれば音がでるというわけです。そのためかどうか知りませんがUSBやWindows、MacOSなどに詳しくないオーディオメーカーなどがPCM2704を採用しているようですが、USBの信号線の処理などがメチャクチャで信号品質が基準外のようなものがあったりして、お手軽に作っているとしか思えないようなものも見かけます。その上、USBオーディオの伝送などについて珍説を披歴していたり、「CDを超えた」と大きく豪語していたりします。何も知らずにものを作っているのでケーブルや振動対策で音質向上を図る以外の術がないと思いますが、そんなに簡単にCDの音質を超えられるとは思えません。CDはUSBより10年以上の長い歴史があり、多くの人達がいい音を出すために努力を積み重ねてきたはずです。もちろんCDという方式にはいろんな問題や限界があり、ある部分に関してはPCオーディオ、USBオーディオの方が優れていることもあります。しかしPCオーディオとUSBオーディオにもいろいろ問題があり、中には致命的とさえ言えるものもあります。正しい知識に基づく検証や改良が行われないままでは「超えられてしまったCD」やCDの開発にかかわってきた人達だって堪らないと思います。また、USBオーディオやPCオーディオも進歩がないと思います。

　私たちのPCオーディオの「いい音」の基準はとてもシンプルです。開発作業中には澤野工房から発売されているトヌーナイソーのアルバムをよく聴いています。7月28日に「なにわの日Jazzコンサート」というのが大阪市浪速区の通天閣の展望ホールで行われ、トヌーナイソー本人がやってきました。通天閣の展望ホールですので、鉄骨があちこちにあって音響効果など良いわけがありませんし、ピアノもベーゼンドルファーではなく人力で階段を担ぎあげたYAMAHAです。トヌーの前に大石学さんが演奏されましたが、弾く人によって同じピアノから全く違った表情の音が出ることに感心しました。そしてトヌーが背中を丸めて最初のピアノタッチの瞬間に出る「コロッコロッ」としたトヌーの人柄そのもののような音を生で聴くことができました。その時に、今までUSB DACの開発中に聴いていた音を思い出し「こりゃあかん、あんな音出してたらトヌー泣きそうや」と恥じ入りました。トヌーを泣かせないような音を出すこと、それが目下のUSB DACの開発の「いい音」の基準であり、演奏者が表現したいことをきちんと伝えられるようなUSBオーディオインターフェイスをつくるのが当面の目標です。もし、それを実現するのにUSBオーディオよりもっといい手段があれば開発テーマをそちらに移すことになると思います。

　前置きが長くなりましたが、本連載ではUSBオーディオの仕組みや問題点などについて説明してゆきたいと思います。例によって、測定データなどを示しながら行いますのでいつ連載が終わるのかわかりませんが続けてゆきたいと思います。

　P.S.）カット写真は、USBオーディオの最近の実験基板類や、最近発売したRAL-2496UT1の基板です。

#31 HDMIのAudio伝送について その５

　しばらく更新を怠っている間に何通かコメントを頂きました。そのコメントに対する回答と併せて今回はAudioデータのサンプリングについてお話したいと思います。

　Audioデータは前回お話したようにデータアイランド期間中にPacketの形でSourceからSinkへ送られます。
ちなみに、前回の図30-1ですが、各Sub PacketのStatusバイトの説明が逆になっていました。図を訂正いたしましたので、再度#30を参照してください。上位4bitはR（Ch.2）の、下位4bitはL（Ch.1）の各Statusを示します。「とだしょー」さんからご指摘を頂きました。ありがとうございました。訂正してお詫びいたします。

　Audio用の伝送フォーマットのひとつであるI2Sではサンプリングクロックとワードクロック（LRCLK）がデータとセットになっています。I2Sは3本の信号線が必要ですので、S/PDIFでは1本の信号線でデータとクロックを同時に送るためにBi-Phaseという変調方式を採用してデータにクロックを埋め込んでいました。しかし、HDMIのAudio Sample PacketはUSB Audioなどと同様にデータのみで構成されており、一見しただけではサンプリング周波数もbit長もわかりません。しかし、実際にはS/PDIFのChannel Statusと同様に、各Packetに1bitずつ含まれている情報を192個つなぎ合わせるとサンプリングクロックの周波数（fs、C24からC27の4bit）やデータの長さなどがわかります。Audio Sample Packetとは別にAudio Info PacketというのもSourceから送られてきますが、内容は図31-1のようにSpeakerの配置などの情報のみです。また、さらにそれらとは別のACR packet（Audio Clock Regeneration --- HDMIの仕様書ではACRをこのように記述していますが、Silicon ImageのデータシートではACRのことをAudio Clock Recoveryと記述しています。） で特定の係数を伝えるというHDMI独自の方法でSource側からSink側へサンプリングクロックの情報を伝えています。

図31-1　Audio Information Packet

　まず、Source側ではAudio dataのサンプリングクロックの周波数（fs）を128倍します。CDでは44.1kHzですが、Blu-Rayでは48kHzが主に使用されています。これを128倍したものをNと名前をつけた整数で分周（devide）します。48,000Hz x 128 = 6,144,000（6.144MHz）となりますから、仮にNを6144として割り算を実行すると商は1,000（1kHz）となります。この商をカウンタにプリセットしてPixel Clockをカウントします。要するに商で示される期間（周波数の逆数）はTMDS Clock何個分かということを数えるわけです。仮にTMDS Clockを148.5MHzとすると商は1kHzでしたので、カウント数は148,500個となります。このカウント数のことをCTS（Cycle Time　Stamp）値としてN値と共にACR PacketでSinkに伝えます。ACR packetのフォーマットは図31-2を参照してください。

図31-2 Audio Clock Regeneration Packet

  HDMIの仕様書ではNとCTSの推奨値を表にしています。よく使われているものだけ抜粋したのが表31-1です。

表31-1　各サンプリングレート、解像度でのN値、CTS値の推奨値（HDMI 1.3a仕様書より抜粋）

基本的に48kHz系はNで分周後、1kHzになるようにNの値が推奨され、44.1kHz系は0.9kHzになるように推奨されています。CTSの値は単純に1kHzか0.9kHzをTMDS Clockの周波数で割ったものです。実際にHDMI Source機器としてSONY PS3やPioneer BDP-LX80ではN,CTSとしてどんな値をACR PacketにSetして送り出しているのか調べてみました。表31-2の値はHDMI receiver LSIとしてSiI9135を使用し、自作のdebuggerでH/WでSetされている N Value, CTS Valueレジスタの値を読みだしたものです。

表31-2　実際に使用されている N値、CTS値 の例。

　LX80でBlu-Ray（USAのFry'sでなぜか特価US$18.99で売っていた"i-Robot"）を再生した場合、解像度を1080iまたは1080pに設定するとHDMI 1.3a仕様書の推奨値とおりのN,CTSが使用されていることがわかりました。PS3の場合、Home画面で1080pに設定した場合や、Blu-Ray（”Night Museum", DTS-HD MAをPS3でLPCM 5.1ch. 24/48kにデコードした場合）を1080p@60で再生した場合は仕様書の148.5/1.001欄の推奨値とおりのN,CTS値が使用されています。映画と同じ1080p@24pモードで再生した場合は、Blue-RayのタイトルによってCTS値が1bitだけ異なります。これはカウンタによる実測値を反映しているためなのかどうかは定かではありませんが、実際に2，3種のHDMI transmitterのFirmwareを調べてみると、LSI内部のカウンタの値がH/WでそのままACR packetにセットされて送信されるものと、packet用の送信Buffer Registerにソフトウェアで固定値をSetしているものがあります。

　Sink側では、ACR Packetで受け取ったN,CTS値とTMDSクロックの周波数から逆算してAudio dataのサンプリングクロックの周波数（fs）を算出します。TMDSクロックをCTSの数だけ数えた値をN倍して128で割ればfsが求められます。実際はHDMI Receiver内部のレジスタにH/Wで検出したfs値がSetされていますので、Firmwareで計算する必要はありません。Audio Sample PacketのCh.StatusもCheckしているのかどうか知りませんが、CTS値が多少変動してもfsが"Unknown"になることはほとんどありません。

　HDMI Receiverの次段にDACやDIT（S/PDIFコンバータ）を接続するためにはAudio Sample Packetデータに元のサンプリングクロック（fs）と同じ周波数のLRCLK（WCLK）、データを各bitごとにサンプリングするSCLK（BCLK）の二つのクロック信号を追加し、Packetデータを各bitごとのシリアルデータ（SDATA)に変換してI2S信号を生成しなければなりません。さらにそれ以外にDACやDITの内部動作の基準になるMCLKが必要になります。MCLKは通常、fsを256倍したものや512倍したものが使用されます。128倍（128fs）も使用されないことはありませんがfsが一般的によく使用される48kHzや44.1kHzではなく96kHzや192kHzの場合に限られます。HDMIの場合、MCLKとしてTMDS ClockとN,CTS値から生成した128fsを使用できないのかとも思いますが、HDMI 1.3aの仕様書ではMCLKについては何も触れられていませんし、市販されているHDMI Receiver LSIにはその128fsをLSIから取り出すための端子も見当たりません。
　しかし、DACやDITから見た場合、MCLKとLRCLKなどの位相は一致している必要があります。HDMI Receiverとして販売されているLSIはAudio Clock用としてMCLK生成用に水晶発振回路を内蔵しています。たとえばSiI9135では28.322MHzの水晶発振子を使用するようにデータシートには記載されており、DAC用のMCLK出力とI2S信号作成用のMCLK入力の倍数（128,256,382,512など）を設定するレジスタがあります。それから推測すると、水晶発振子でMCLKを作り、それをTMDS信号から作成したfsに同期させてI2S出力を作っているのではないかと思いますが正確に実験して確認したわけではありません。

　もうひとつ不思議なのがVideoとAudioの同期に関することです。i-Link（IEEE1394）のDV信号やDVD-CAMなどの信号はVideo信号とAudio信号が別々に圧縮されているため、Time Code（Stamp, Cycle Time、上記のCTSもCycle Time Stampですが、フレームの最初から時系列で入っているとは思えず、前のフレームのものかどうか値をCheckするようなことはできないように思われます）のような仕組があり、VideoとAudioの同期を取っていますが、HDMIではVideo信号とAudio信号の共通のClockがTMDS Clockのみですので、どのようにして同期を取っているのか調査中です。Audio CDではSub-Q信号というSub Track（音声が記録されているAudio Trackに並行したTrack）があり、並行するAudio Trackの「そのあたりの位置！」がCD全体の先頭からxx分ｘｘ秒xxにあるのか、曲の先頭からyy分yy秒yyに相当するのかという情報を得ることができます。
Blu-Rayなどの場合はどういう仕組みなのか現在、調査勉強中です。

　次回はもう少し、実験を続けながらいろんなPacketについて話をすすめたいと思っています。

いただいたコメントについて

（1）「ほげほげ」さんから、昨年11月13日の記事「#27　HDMIのAudio伝送について　その1」についてコメントをいただきました。コメント全文はコメント欄を参照してください。文章の前後関係を調べるために出典を探したのですが、CQ出版刊「Design Wave」2008年 4月号79ページ　（「HDMIの基礎知識」柴田修氏執筆）からでしょうか。

　ご質問は
------------------------------------------------------------------
「（Receiver側で独自に水晶発振で生成したクロックと同期させる）」と言うことは、下記の説明は間違いということでよろしいでしょうか？
------------------------------------------------------------------
ということですが、当該記事の内容は間違いではありません。元のAudio データがサンプリングされたfs（128fs）をどのようにしてSource機器-Sink機器間で伝えるかということを書いているだけです。私の方は、I2S信号を作成する（I2S信号に同期させる）ためのMCLKをSink機器側で生成して、TMDS信号から作成した信号に同期させるということを書いていますので、両方が補完し合うような関係にあると思います。仕様書にはSink側のRegenerationの方法について特に規定はされていませんので話がややこしくなっていると思います。

（2）「とだしょー」さんから2009年1月8日の記事「#30 HDMIのAudio伝送について　その4」についてコメントをいただきました。全文はこちらを参照してください。

　ご質問は
-------------------------------------------------------------------------
HDMI規格 1.3a 7章Audioで、Figure 7-1において「128*fs」の値をSource DeviceにてN値を用いてDivideしてVideo Clockを用いてCTS値を作っています。
（質問）
この、「128*fs」と言う値はI2SのMCLK値なのでしょうか？
-------------------------------------------------------------------------
　fsはAudioデータのサンプリング周波数です。CDでは44.1kHz、DVDやBlu-Ray（一般的なタイトル）では48kHzとして知られているものです。一方MCLKはI2SやS/PDIFの規格とは関係なく、DACやDITのLSIを動作させるための基準クロックです。CDトランスポートなどで外部クロック入力といわれているのはLRCLK（WCLK）でサンプリング周波数と同じものですが、機器内部のPLLでこれを256倍くらいに逓倍し、DITの動作の基準となるMCLKとしています。TMDS ClockとN,CTS値から作った128fsをそのままあるいは2逓倍してDACやDIT用のMCLKとすることもできないことはないと思いますが、途中で止まったりすると、DACやDITをそのたびにReset/初期化しなければならなくなるのが問題と思います。また、現実にHDMI Receiverからは復元した128fsをMCLKとして取り出すことはできません。128fsとしたのは、N値やCTS値をBinaryで作成するにあたって、20bitに収めるなどの理由があったのではないかと思います。

他にも同じ「とだしょー」さんと「ほげほげ」さんから関連したコメントをいただいていますが、上記の回答に含んでいますのでご了承ください。

#30 HDMIのAudio伝送について その4

　本blogをお読みいただいている皆さん、あけましておめでとうございます。本blogも2月で3年目を迎えることになります。いろいろとものを実際につくりながら、測定して実験して試聴を行い、またつくりなおして....という試行錯誤を繰り返しながら記事を書いていますので遅々として進みませんが本年もよろしくお願いいたします。

3.　Audio信号はどのようなフォーマットで送られるのか。

　HDMIのAudio信号はS/PDIFと同じようなIEC60958/61937に準拠したパケットの形で伝送されているということは、これまでも何度かお話いたしました。図-30-1は実際にHDMIのライン上で伝送されているAudio Sample Packetのフォーマットです。

図-30-1　Audio Sample Packetの構造

後ほど説明しますが、Data island（データアイランド）区間内に伝送されるいろんなデータパケットは同じフォーマットをしており、HB0からHB2までの3バイト（1バイトはb7..b0の8bitです）のパケットヘッダによって区別できるようになっています。
　パケットヘッダ情報とパケットの種類（Packet Type）については表-30-1を参照してください。

表-30-1　HB0内のPacket Typeの値とその意味

図-30-1ではPacket Typeが0x02（binaryで'0000 0010'）ですので、リニアPCMもしくはDolby 5.1などのAudioデータを格納したAudio Sample Packetであることがわかります。Audio Sample packetであってもDSD（SACDの1bit Audio）信号や、DTS HD Master Audio,Dolby True HDなどのHD Audio信号などのAudio Sample Dataを含む場合はPacket Typeの値がそれぞれ異なります。しかし、基本的なフォーマットは同じです。

　HB0に続く、HB1,HB2は各パケット固有のフォーマットが決められており、Audio Sample Data Packetの場合は図-30-1のように決められています。HB1では上位3bit（b7..b5）は'0'固定、b4のオレンジ色の'L'というbitはPacket Layoutを示します。1bitだけですので'0'か'1'のどちらかですが、パケット内のAudio信号のチャンネル数を示します。'0'の場合はAudio Sample dataが2ch（Stereo）であることを示します。Sub Packetひとつでひと組のデータを表現できますので、ひとつのパケットに含まれるAudio Sample Data数は最大で4組（Sub packet 0から3まで）です。何組のデータを含んでいるかどうかということはHB1の下位4bitで表現されます。
　Packet Layout bitが'1'の場合はAudio Dataが8chであることを示し、Sub Packet#0がFront L,R、Sub packet#1のCh.1がCenter、Ch.2がSub Woofer、Sub Packet#2のCh.1,2がリアのL,R、Sub Packet#3のCh.1,2がサラウンド（リスナーの左右の横）のL,Rというように割り当てられています。この場合はひとつのパケットにはひと組のサンプリングデータしか収容できません。

　HB1の下位4bit（b3..b0）は4個のSub packetそれぞれの使用、未使用を示し、'1'なら使用、'0'なら未使用です。たとえばL-PCM 5.1ch.の場合はLayoutが'1'= 8chですが、HB1の下位4bitを'0111'（0x7）とSetすることによって、Sub Packet 3を未使用ということにし、Sub Packet 3内部のデータを無視するようにSink側に伝えることができます。同様にPacket Layout bitが'0'（2ch.Stereo）でHB1の下位bitが'0011'（0x3）の場合はSub Packet 0,1に有効なデータが含まれているが、Sub Packet 2,3には有効なデータが含まれていないことを示します。

　HB2の上位4bitは対応するSub PacketがS/PDIFなどと同じIEC60958の1ブロックすなわち192フレームの先頭フレーム（Frame#0）に相当する場合に'1'がセットされます。その他の場合は'0'がセットされています。以前に本Blogで説明したように、S/PDIFなどでは各フレームを構成するサブフレームにはプリアンブルと呼ばれるヘッダ部があり、先頭フレーム（Frame#0のLch. Sub Frame）のプリアンブルは'B'、その他のSub Frameの先頭は'M'（L ch.）または'W'（R ch.）と決められていました。HDMIのAudio Sample Dataにはサンプリングされたデータごとにこのようなプリアンブルはありませんので、HB2の上位4bitをかわりに使用しています。なぜ、192フレームごとに、区切らなければならないのかというとHDMIのAudio Sample DataにもS/PDIFなどと同様なChannnel Status bitがくっついているためです。このChannel Status bitのフォーマットや意味は同じですので、過去の本Blogを参照してください。

　HB2の下位4bitは対応するSub Packet内のデータが有効な場合（HB1の対応する下位4bitが'1'にセットされている場合）、そのデータが'flat line'かどうかを示します。Audio信号は交流ですので無信号時（音がなにもしない）はオシロスコープ上では横1直線の'flat line'となります。しかし、それに対応するSub Packet内部のデータは0x000000（24bit）となっているわけではありません。これらの各bitはL-PCM 5.1ch.の場合にSub packet 3を有効にして（HB1のbit3を'1'にセット）、HB2のbit3を'1'にセットすることにより、L,R,サラウンドのスピーカーからの音を止めるような場合に使用することができます。実際のHDMI伝送ではSink（受信側の機器）がHDMIから2画面続けてAudio Sample Packetが来ないということを検出すると相手機器（Source）がHDMI機器ではなく、DVI機器であると解釈してHDMIモードを解除し、DVIモード（RGB 24bit）に自分自身を切り替えてしまいます。HDMI Source側がそれを知らずにYCbCrで映像データを送ると、画面が緑一色になってしまったりするというトラブルが発生します。そうならないように、HDMI Sourceは音声なしの無声映画・映像であってもデータ・アイランド区間内で無音Packetや、General Control Packet,Null Packetなどを定期的に送信し続けなければなりません。HB2の下位bitはこのような目的で無音Packetをつくるために使用されます。

　Sub packetの詳細も図-30-1を参照してください。各Ch.（L,R）のサンプリングデータはI2SやS/PDIFなどと同様それぞれ24bit長です。各Ch. 3バイト長（8bit x 3）のデータ2個の最後部には各Ch.あたり4bit（計1Byte）のStatus bitがあります。各bitの意味は過去の本Blog（S/PDIF編）を参照してください。

　1920x1080p@60HzでBRのHD映像を再生している場合、音声が16bit/48kHzとすると、L-PCMのMulti Channelでは1mSあたりサンプリングデータが48組なので1画面 16.6mS（60Hz）の間に796組か797組（48x16.6）のAudio Sample packetをHDMI Sinkに対して送信しなければなりません。しかも、水平帰線区間を縫って伝送しなければならないので、S/PDIFのようにリアルタイム（サンプリングクロックに同期させて、1mSの間にL,Rを48組）でノンキに送っているわけにはゆきません。

　次回か次々回はそのための工夫について説明します。その間にCES2009で見つけたものの報告が割り込むかも知れません。