（
この記事の続きです。）
まず、一般的なUSB DACの規格に関して説明します。
USBには大きく分けて、コントロール転送、バルク転送、アイソクロナス転送ってのがあります。
USB DACをPC等から使うには、USB Audio Class(UAC)と言う規格を使います。
UACには3つのバージョンがあり、DSDの転送に関してはVersion3で正式に規格となりました。
このVersion3ですが、出来立てのため、現在 USB DACで採用しているメーカーはありません。しかもDSDの規格が無いということから、いろいろな思惑でいろいろな方式があります。
ただし、ほとんどのメーカーはUAC規格の上でいろいろとアイデアをだしており、一般的なのが
DoP(DSD on PCM)と言う形式です。
24ビットのデータの8ビットをDoPのしるし（マーカー）として使って、残りの16ビットにDSDを詰めて転送しようとする形式です。
基本的には、DAC側でPCMとして入ってきたデータをDoPかどうか判断できればよいので、UACの規格の上で成り立ちます。そのため、DSDをサポートしているDACはほぼこれをサポートしています。UACの転送方式はアイソクロナス転送の中でも、お互いのデータ量を調整できるAsyncronous転送と言う転送を使っています。
で、問題のこのCMD-18もDoPをサポートしています。ただ、サポートの仕方が独特なのです。
そもそもDoPには欠点があり、サポートできる最高の周波数が半分になってしまうのです。（もともと32ビット単位で周波数が定義されているDSDなので、16ビットを２回に分けて送るためには倍の速度で送る必要があるため。）
CMD-18の最高周波数はPCMで384kHz/32bitとなっています。この上でDoPをすると、DSD128（周波数で言うと、176.4kHz/24bit)までの再生となります。つまりDSD256が再生できません。DSDを直接送れば、DSD256が対応できます。周波数的には352.8kHz/32bitです。
そこで、このCMD-18のプラットフォームを作った人は考えた（かどうかは定かではないですが）、「どうせDSDをそのまま送るなら別にUAC規格の上に乗ってなくてもよくない？」
と言うわけでWindowsの専用ドライバを使う場合は、UAC規格とは関係なく、やりやすい「バルク転送」を使おう。ってことで、バルク転送が使われています。
バルク転送は、Asyncronous転送とは違って、調整ではなく、ホストから一方的に送りつけて、DAC側が拒否（NAK）したら、受け取る（ACK）まで何度も送る方式です。
当然、ホスト側は受け取るか受け取らないかわからない状態でずっとデータを作り続けるので、DAC側が拒否し続けると、バッファがあふれます。これが、このDACをおすすめできない理由です。バッファがあふれること＝音飛び＝ノイズなので、周波数が高いハイレゾデータでこれが頻繁に起きると、聞くのが堪えられなくなるでしょう。
次に、これがDSDだけなら良いのですが（←良くない）、「DSDとPCM分けてドライバ書くの面倒だし、いっしょにしちゃえ」って言ったかどうかわかりませんが、WindowsのドライバからはPCMもバルク転送されて送ってきます。
あと、一般的ではないので、Windows用のドライバが作られなくなったら、このバルク転送は使えないので、将来を考えるならば、ちゃんとしたメーカーのDSD512対応を買った方が良いです。
ただし、欠点だけではないです。上限が384kHz/32bitのDACでDSD512（705.6kHz/32bit）が再生できるからです？
アシンクロナス転送の欠点は、データ量を周波数に合わせて変化させなければならない。と言う点です。しかし、バルク転送にはその制限がありません。なので、めいっぱい、ホスト側から送りつけて、DAC側の処理に間に合うようにしてやれば、DSD512も再生できるということです。
