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

Comments

[投稿情報: えるえむ]

いつも興味深い記事をありがとうございます。

おそらくUSBオーディオの解釈がジッターがらみで混乱しているのは，PCM270x系チップを使ったUSBオーディオと，TAS1012Bを使ったUSBオーディオとで，どのように動作が違うのかを対比して説明している記事がほとんどないからではないかと思います（TAS1012Bを使っているUSBDACの数が少ないからかもしれませんが）。

特にPCM270x系DACのジッター値が悪いのは先日のimpressの記事でも十分わかりましたが，では何故悪いのでしょうか。
お話をお伺いしていると，通常のUSBオーディオデバイスではPCのクロックの影響をうけないと読めるのに，なぜここまで差が開いているのか不思議です。
御社のUSBDACの記事ではPLLが原因ということが書かれていますが，そのあたりを詳しくご解説頂ければ幸いです。

[投稿情報: hideon]

改めましてはじめまして。
avWatchの記事からたどり着きました。
USBオーディオについて分かりやすく解説いただきありがとうございます。
昔IT業界に居たため（私はUSBドライバを作成していたわけではありませんが）バスマスタ転送やDMA転送などの単語に懐かしさを覚えます。
ブログは非常に分かりやすく書かれていますが、コンピュータやソフトウェアの技術者の多少の知識がないと、一般のオーディオの方が読むと、スタックに積み上げると言うような簡単な表現でも難しいのかな？とも思います。

パソコン内部では1,0のデータやパケットがオーディオクロックとは何の関係もなく動いているだけですが、パケットでなくアナログの音が切り取られてサンプリング波形データそのものが運ばれていると想像しがちなので（※日本語にすると違いが分かりにくいですが）様々な誤解や質問が生じるのでしょう。

ところで、お聞きしたいのですが、現在S/PDIF出力のついたパソコンをオーディオアンプに接続しています。
こちらについては、御社のRAL-2496UT1経由でUSB接続からS/PDIF変換した場合では出力値等は何かしら異なりますか？
今はIT業界から離れて居ますし、S/PDIFの仕様や出力内容については調べた事がないのですが、それこそ稀にバチッとか、ブツッとか言う音が起きますが、CPUの負荷がかかるような他のバックエンド処理が走ったりして起こることなのか？と想像しています。
（アナログで例えるなら、アンプへの入力値が制限を超えた時に起こるような音ですが、それこそアナログデータが送信されているのではないはずなので、何が原因か？と考えています。）
USBとS/PDIFの違いについても合わせてご教授いただけますでしょうか？

[投稿情報: ARABAKI]

はじめて投稿させていただきます。
非常に興味深い話ですので、楽しみに読んでいます。

ちょっとした質問なのですが、Isochronous転送時、同期方式が
Asynchronous、Synchronous、Adaptiveとあると思うのですが、それぞれの場合、
ホスト
側ではどこのモジュールがその制御をおこなっているのでしょうか？Feedbackの
情報など
はどのモジュールで使用されるのでしょうか？
ご教授していただければ幸いです。よろしくお願いいたします。

[投稿情報: ｓｃｍｐ]

初めまして。
次回以降、ジッタの解説をされるようですが、そこで初歩的な質問ですが、ジッタによる再生音はどのように聞こえるのでしょうか？
昔のＬＰ時代にはワウフラッターなどというものがあり、正に音がワウワウと揺れるように聞こえたものですが、デジタル時代になってジッタなどというものが取り沙汰されておりますが、これはデーターの取りこぼしのために音切れが発生すると考えていいのでしょうか？まことに初歩的な質問だすがこのあたりの説明もよろしくお願いします。

[投稿情報: ひらっち]

初めまして。
大変勉強になりました。

次の記事が待てず、質問してしまいました。
USBのオーディオクロックが高精度の固定クロックを使っており、PLLによるオーディオクロック生成も正確と仮定します。
その場合、論点は、①SOFの間隔が一定でありオーバーフロー、アンダーフローが生じないか？、②パケットデータがどこかで欠落していないか？、③クロック生成やその他の動作を安定的に行うためのクリーンで十分な電源が確保出来ているか、ということになりますでしょうか？

受側機器側以外でも、PCの送り出し精度とUSBケーブルの転送能力が①～②に影響を与え、バスパワーの場合には、USBケーブルが③にも影響を与えるのではないかと思っております。

ご教示の程何卒宜しくお願い致します。