USBオーディオのアシンクロナス転送について

質問

USBオーディオのアシンクロナス転送について
最近出ているUSBインターフェース付きのDACにUSBのデータ転送方式をアシンクロナスにしてジッターをなくし高音質を実現したというものがあります。　USBオーディオはもともとアイソクロナスという非同期モードで送ってましたのでアシンクロナス転送は最初からあったわけで、クロックもUSBのICが作っていましたから、最近の新開発というのは少しおかしいような気がしますがどなたか詳しい方がいらっしゃいましたらよろしくお願い申し上げます。　　アシンクロナス転送という言葉自体は正式なUSBの用語ではなくアイソクロナスというのが正しいと思いますがいかがでしょうか？

回答No.5

hi_kawa

先に言うと新開発アシンクロナスは大嘘です。昔からAsyncのUSBAudioはあります。

USBAudioのアイソクロナス転送にはSync,Asyncの2種類の転送モードがあります。この2種類はマスタークロックの場所が違います。ただしアイソクロナスの周期(1ms)はUSBホストコントローラ同期です。
SyncはPCのUSBホストコントローラの12MHzクロックにUSBAudioが同期し、それがDACのクロックになります。
AsyncはUSBAudioがフロー制御を行い、DACのクロックはUSBAudio側の水晶が使われます。
サンプルレートはAdaptive動作でUSBAudioデバイスの認証が必要です。認証されない場合には基本的には認証される高いサンプルレートによりOSのソフトSRC経由で再生されます。

Windowsの場合には
基本的にWindows7(2011年10月現在)までの標準USBオーディオデバイスのドライバがAsyncに対応していないのでSyncモード前提の設計になりUSBAudioのマスタークロックはUSBホストコントローラの12MHzです。
逆に専用ドライバのモデルは殆どAsyncモード（一般的にアシンクロナスと言う？）です。

PCM270Xは標準ドライバ専用なのでSyncモードです。内部のPLLでUSBホストコントローラ側に同期しています。水晶は単純にPCM270Xの内部動作用です。
また、たまに見かけますが、大きいRAMを使い水晶をマスタークロックにしているものもあるようですが、力技なのでいつ音が飛ぶかわかりません。
変わったものとしてはPhilipsのUDA1325Hで、Adaptiveの許容範囲が広く(5kHz-55Khz連続(1Hz単位))、その広範囲のサンプルレートに完全に追従できますが、ジッタは非常に大きいようです。この場合にはデジタル出力はSRCを入れてレートの確定とジッタの影響を減らしているようです。

無難なのはCreativeで、USB1.1専用の物でもほぼ全てのUSBAudioが専用ドライバを入れるとAsyncモードになります。嬉しいのはOSの付属ドライバでも使え、その場合にはSync動作になるので便利です。
RolandもAdvanceモードが使える物はAsyncになります。現行品は全てOKと思います。

ちなみにAsyncのものではAudio Repeaterというループバックソフトを入れるとUSBAudioデバイス毎にバッファの残量の増減が変わるのでそれで確認できますが、相手が水晶なので確認に時間はかかります。まあ、中を見て24.576とかついていて専用ドライバなら間違いなくAsyncですが、、、。

ただ、USB1.1でUHCIだとAsync,SyncどちらでもCPU負荷が上がったりCPUが遅いと音とびもあるし、やっぱりUSB2対応品が良いですね。

ジッタ云々言うのであれば外部同期が取れる音楽用のIEEE1394の物が絶対に良いです。その際にはマスタークロックを別に用意する必要がありますが、、、。
USBAudioは高級品はどうなのか知りませんが、たいていの物はオーディオ的に見ておもちゃのような物です。購入するときは慎重にお選びください。

回答No.4

yosifuji2002

#1のものです。

以下は別の質問への回答と同じものですが、この議論の参考になりますので、再度投稿します。

志賀＠高槻　の中に出てくるデータです。

-----------------------------------------------------------------

クロックが聴感に影響するのかどうかについての論文を見つけました。

ここでの結論は、CDクロックの誤差によるジッタが原因での、検知可能な影響は認めれられないというものです。

参考までにご覧ください。

参考URL：http://www.ne.jp/asahi/shiga/home/MyRoom/Jitter.pdf

回答No.3

Yorkminster

>> アイソクロナスモードのUSB転送でのジッターはPC側の問題ではなく、受け側の問題である //

私がNo.2の回答の中で挙げたリンク先の記述を見る限り、そういうことだろう、と理解しました。

Isochronous transferの場合、パソコン側のUSBコントローラは、PCMデータをパケット化してスタックし、順番に送り出す、という動作しかせず、オーディオクロックをUSBデバイスに送らないということのようです。

そうすると、いわゆるジッタの問題、つまり「オーディオクロックの揺れ」は、パソコン側の責任ではないというか、もともとUSB Audio Deviceの規格では何らの保証もされていない、ということになると思います。

>> FIFOの大きさが足りない //

そういう話ではないと思います。そもそも、バッファの容量をオーバーしてしまうとデータの連続性が失われるので、いわゆる「音飛び」のような形で表れるのではないでしょうか。

ラトックのブログに詳述されていますが、これを回避するためには、バッファの容量を大きくとる以外に、2つのバッファから交互に読み出す、小容量のバッファを「ハムスターの回し車」のように自転車操業して間に合わせる（RAL-2496UT1がこれらしい）、などいろいろな方法があるようです。

ただ、これはデータの連続性を確保するための方法であって、「クロックの精度」とは直接には関係しないでしょう。

>> ケットごとにPLLをロックしなおしするのでその時のPLLの再同期時のJITTERが問題である //

そういうことではないかと理解しています。

Synchronousモードの場合、1パケット当たりのデータ長を見て、それが44ないし45だと44.1kHzのデータ、48だと48kHzのデータと判断するようです。ところが、データ長がいくつだったか、というのを先読みする構造ではないために、次のパケットの先頭（SOF）が来た時点で、事後的に「このパケットは44個入りだった」と分かり、「じゃあ44.1kHzでD/A変換しよう」と決まる。それにも関わらず、「いつの時点でSOFが来るか」が保証されていないので、クロックを生成するタイミング自体がズレる場合がある。ということでしょう。

そこで、クロックの生成をSOFに依存せず、いったん「このパケットは44個入りだった」と分かった時点で独自にクロックを作って、それ以降のデータは全部それで処理してしまう。48個入りのパケットが来たら、そのとき以降は48kHzのクロックに切り替える。という割り切った処理をすれば、クロックの精度は発信器の精度とほぼ等しくなるので、少なくともSynchronousモードに比べれば遥かに高精度にできる保証がある、ということではないでしょうか。

その場合でも、「いつの時点でSOFが来るか」は保証の限りでないので、バッファを巧みに使ってデータが途切れないようにする必要がある、というくだりで、バッファの話が出てきているのだと思います。

相変わらず、デジタル回路のことが分かっていない人間のいうことなので、あまり信用できない回答ではありますが...

回答No.2

Yorkminster

全くのド素人なので、回答どころかかえって混乱させるだけかも知れませんが...

>> アシンクロナス転送という言葉自体は正式なUSBの用語ではなくアイソクロナスというのが正しいと思いますが //

規格書の上では、USB Audioは基本的にIsochronous transferで（Audio Device Classに準拠せずに、USBの一般規格に沿ってAudio Streamを転送することも不可能ではないらしい？）、同期方法としてAsynchronous、Synchronous、Adaptiveの各モードがある、とされています。したがって、「アシンクロナス」というのは「アイソクロナス転送における同期方法の1つ」なので、同列に比較するのは誤り、ということになるでしょう。

http://www.usb.org/developers/devclass_docs/
（Audio Device Document 1.0の18～19ページを参照）

ところで、「アシンクロナス」とか「アイソクロナス」とかの用語を一般人（というか普通の(?)オーディオマニア）に広めたのはラトックシステムのRAL-2496UT1ではないかと思っているのですが、その説明によれば、大要、

・従来のUSBオーディオデバイスは、送られてきたパケットのデータ長からサンプリングレートを判断してオーディオクロックを生成していた。

・本機（RAL-2496UT1）は、独自にオーディオクロックを生成する。

とされています。

http://www.rexpccard.co.jp/products/subpage/ral2496ut1.html

また、同じくラトックのブログによると、大要、USBオーディオデバイスではSOF (Start Of Frame)を受け取って初めて1パケット当たりのデータ長が分かり、クロックが決定できるが、SOFがいつ送られてくるかが正確ではない、ということのようです。

http://blog.ratocsystems.com/pcaudio/cat634009/

この説明を、上記の3つの同期方法に照らし合わせると、Synchronousモードでは「SOF (Start Of Frame)に同期させる」、Asynchronousモードでは「SOFに同期させない」というのに対応するように読めます。

つまり、

・従来の多くのUSBオーディオデバイスは、Synchronous Isochronousモードで動作していた。ところが、USBオーディオという規格自体、1パケットの転送間隔（1msで不変）内であればどのタイミングでデバイス側にデータが届いても良いことになっている。そして、SOFを受信しないと「前のデータの終わり」が分からないので、データ長が不明確になりがちである。USBオーディオは、データ長に依存してオーディオクロックを決める仕組みなので、これではクロック精度が著しく低下する。

・本機（RAL-2496UT1）は、パケットサイズに応じてオーディオクロックを判断するが、いったんクロックを決定した後は、SOFとは無関係に、独自のクロックで動作する（Asynchronous Isochronousモード）。したがって、明らかにサンプリングレートの異なるオーディオデータストリームが来ない限り、安定的なクロックを供給できる。

ということのようです。

ひとことで片付けるなら、「従来はSynchronous Isochronousモードなのでオーディオクロックが不安定」、「Asynchronous Isochronousモードならばオーディオクロックが安定する」ということでしょう。

ただ、これはあくまで「RAL-2496UT1に関する説明」と、それに必要な限りでの一般論なので、あらゆるUSBオーディオデバイスでそうなのだ、とまでいえるかは分かりません。また、この手の民生向け、再生専用のデバイスはともかく、業務用の録音デバイスの場合にも、話は変わってくるでしょう。

分かっていない人間が聞きかじり/受け売りで説明しているだけなので、かなり怪しいですが...

お礼

ありがとうございます。とても詳しいご説明で参考になりました。アイソクロナスモードのUSB転送でのジッターはPC側の問題ではなく、受け側の問題であるということでしょうか？　PCM2704などはFIFOが内臓されていて、外部水晶CLKでそれを読みますが、そのFIFOの大きさが足りないということでしょうか？　　あるいはパケットごとにPLLをロックしなおしするのでその時のPLLの再同期時のJITTERが問題であるということでしょうか？　何卒よろしくお願い申し上げます。

回答No.1

yosifuji2002

CDのドライブは、デジタルデータを読み取った後でメモリーに蓄え、そのデータを水晶クロックに同期させてDACに送り出します。この際CDドライブの回転ムラがあっても、メモリーのデータを増減させてそのムラによる読み取り速度の誤差を吸収します。いわば手こぎポンプの脈動する水を一度バケツで受けて、その反対側の蛇口から一定水量で出してゆくような感じです。

DACへは回転速度に関係なく水晶の精度（デジタル時計と同じですから、1月に15秒程度の誤差）でDACはアナログ変換しますので、クロックの誤差は人間には検知不可能な精度です。
したがって、DACとPCのクロックがあっていようが不一致であろうが一切関係ありません。

私の好きなサイトの　志賀＠高槻　の志賀さんの説で「定性と定量」ということがあります。
つまり水晶の誤差がDACの精度に影響することは事実かもしれない。これが定性的発想。しかしそれがどの程度の量的影響があるかは別問題で、それが人間の聴力上検知外の微量でしかないことは十分ありうる。これが定量。オーディオの俗説はこの2つの概念を常に自分に都合の良いほうだけ言う珍説が多いということです。

素人がこれを言うのは個人の勝手だが、メーカーがこれを言ったら騙しに近いと思います。

ジッタが音にどういう影響をすると考えているのかわかりませんが、これらがCDデジタルの良く考えられた仕組みのひとつで、この誤差がわかる人はまさに神業と言えます。

お礼

ありがとうございます。定性的定量的な概念はとても参考になりました。AUDIOを科学的に追及するには定量的な解析が大事ですね。でもAUDIを楽しむという観点からは定性的なアプローチが支持されやすいんでしょうか。　両方のバランスを保っていきたいと思いました。