#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変換用のクロックに影響する」という説は正しくないということを理解しておいてください。