(memo)接続方法としてのUSB/LAN/iLink、時間吸収制御としてのISO/ASYNC/FLOW、出力方法の分別としてのDAC/DDC、2回目。

(過去:(memo)接続方法としてのUSB/LAN/iLink、時間吸収制御としてのISO/ASYNC/FLOW、出力方法の分別としてのDAC/DDC。 - 雑記/えもじならべあそび)
(過去:揺れすぎバス(USB)問題への対策案が、プラセボなのかどうかをチェックする方法を見つけた……ので、ただいまノンブラインドテスト中。 - 雑記/えもじならべあそび)

　注：これはいまだに、個人的なメモの域を脱していません。
　このなかには、技術的な間違いがあったり、勝手に変な名前をつけていたりします。
　あとからこれを修正したり、別記事化したりする……と思うので、現状については放置推奨。

　……いろんなアレコレに、勝手に名前を付けてみるテスト。

伝送系の時間軸対策区分	PCI	USB	LAN	iLink	適用例
Unbuffered-ISO(1)	──	×(1.x系)	──	×	USBのうち、一般的な1.x系
Timeshift-ISO	──	×(1.x系)を○に	──	──	RAL-HUB02ほか、タイムシフトHUB
Unbuffered-ISO(2)	○	○(2.x系)	──	──	PCIは一般的なもの、USBは2.x系
Buffered-ISO	──	○	──	──	S/P DIF系高級機にある
Narrow-ASYNC	──	○	──	──	RATOCほか(はつかねずみ車方式)
Wide-ASYNC	──	○	──	──	Buffered-ISOのUSB版(ASYNC系一般)
Flow-ISO	──	──	──	○	iLink用速度微調整法
Flow-DATA	──	──	○	──	LANDAC、DLNA機器、ストレージもどきDAC

　……これらの「伝送系」時間軸ズレと、あとは後続機の「機器内部」時間軸ズレとの加算値が、実際に出力されるときの「総合的な」時間軸ズレとなる……と。
　一般的なデバイスだと、「機器内部」時間軸ズレなんてタカが知れてる(せいぜい数十ppm)から、そーゆー機器の後段にもう一段AutoGEQ(同様に数十ppm)をはさむとかしなければ、スピーカーで聞いたときの違和感が表面化しにくい。

　一方で、伝送系は事情が複雑？で、LANとiLinkではフロー制御が一般的だし、PCIとUSB2.x系はタイミングの関係でズレが少ない。
　ただし、USBのうち1.xに限っては、ポン付けだとブレの影響が排除しきれない。この対策は5方式ある。

• USB2.x AudioClass対応DACに買い換える──抜本的対策になるけど、まだ標準デバイスドライバが整備されているとは言いがたいので、もう少し待つほうがいいと思う。
• ストレージクラスで駆動する変態DAC/DDCを使う──能動的フロー制御になるので、機器内部ズレのみで済む。再生ソフト依存が強いところがネック。
• ASYNC受信で取り回す──メモリー容量の大小差はあっても、受動的フロー制御になるので、そこで補正し切れなかったの分のズレ＋機器内部ズレのみで済む。機種によっては(能動的フロー制御を併用するための)デバイスドライバを必要とする点に注意。
• タイムシフトHUBにUSB-DAC(1.x)を直付け──2.x→1.xのパケット変換時にタイミングを合わせこむので、そこで補正し切れなかったの分のズレ＋機器内部ズレのみで済む。ハードウェア補正なのでカネが掛かるのが難点。
• ASIOなどのソフトウェア技術を使って、送出側の遅延自体を小さくすることによって、間接的にブレを減らす──システムによる効果差があり、効果が得られない(＝遅延を小さくしようとすると、ぶちぶちと音が途切れる)システムがある点に注意。こういった場合は、ハードウェアで辻褄合わせ(またはハードへのフロー制御送り出し)できるシステムを使うしかない。

　もっとも、USB1.x系の場合であっても、「気になる人だけ、対策すれば良い」レベルの話なので、今後どういう風に移り変わっていくのかは不明。
　それと、RATOCがやったそれを「大手チップメーカーが採用する」ようになれば、USB1.x系でも普通に解消できる問題……なので、どっちにせよ「時が解決してくれる気がする問題」のような気はする。
　それを待っていられない人にとっての、対策機器が揃った……という意味では、少し前とは違ってだいぶ豊かになった……というのが現状、と。

　……ってゆーか、こんなことを考えなくても、普通に(≒それなりに)オーディオ的に使えるUSB-DACで満ち溢れた世界になってほしいんですけど。
　もー、考えるのもめんどくさくて仕方が無いです……。