約3か月間お休みさせて頂き申し訳ございませんでした。その間に調べたことや実験したことなどを話題に再開したいと思います。休んでいる間は写真のようなものを作ったり、実験したりしておりました。
それだけではなく、東京や大阪で開催されたオーディオ関係の展示会などにも足を運んで、いろいろ音を聴いたり、イベントでの評論や会場での噂を聞いたりしてきました。
LINNのDSシリーズについても比較的時間をかけて聴く機会にも恵まれました。その時、オヤッと思ったのはDSシリーズと私たちが実験しているPC-Audioの音に何かしら似通ったところがあるということでした。CDマスタのデータを忠実に(正確に)DACまで伝送するという考え方は共通でDACも同じWolfsonを使っているとは言え、アンプもスピーカも違うにもかかわらず、何か音の出方に共通点があるような気がしました。DACをBB(TI)に換えると少し変化がありますが、CDプレイヤやCDトランスポートの再生とどこか違う、Digital Transport共通の何かがあるようです。
「LINNは凄い、革新的だ」というような評論家の記事や談話を、PC_Audioと電話口で言っただけで門前払いを喰わせたような雑誌が主要な記事として掲載するようになったのはLINNの功績だと思いますが、同じ部屋や誌面でAudio GradeのLANケーブルとか、HDDではなくSSDを使用したNASの方がいい音がすると手放しで称賛しているのは感心できませんでした。媒体がHDDであろうがSSDであろうが、何度か読み込み(Drive内部のRAM上のバッファに)を行い、エラー検出、リトライを行った後に上位のソフトウェアに引き渡されます。ましてやLINNのDSシリーズの場合は何度もNetwork Driverの送受信バッファRAMへのコピーが行われ、最後に音楽再生用のバッファRAMに格納されます。そこからDMAで(たぶん)一般のI2SかWolfsonのDSPモード用のI2S信号に変換されてDACに送りこまれているはずです。どうもオーディオ評論家やライタの人達はHDDも回転体なのでCDやアナログレコードのように直接読み込まれている(CDにも1トラック分のバッファはあります)とでも勘違いしているように思えます。CDからエラー訂正を行いながらリッピングしたデータがNetworkを通してNAS上に格納され、そこからNetwork経由でDSシリーズの機器の音楽再生用バッファに格納されたDigital Dataが元のリッピングされたデータと一致しなければおかしいのです。DACまでで音が変わるというのはデータが化けているか、時間軸(データ転送が追い付かず、次のデータとの間に余計なデータが挿入されているか、前のデータの上に後のデータが重なってしまっているか)がずれているかのどちらかで、それらのデータ伝送の誤りが発生していることの方が問題で、ケーブルや記憶媒体を変更して喜んでいるよりは、そっちの方の原因を究明して修正するべきと思います。データに誤りがなければ、LANケーブルが電磁ノイズを放射しているか、GNDにノイズが回り込んでいるか、HDDの動作音や振動、放射ノイズが何かに影響しているかのどれかです。いずれにせよ、そういう設計に問題があると思います。
今回からテーマとするHDMIのAudio伝送に対しても似たような状況です。「HDMIは音が悪い」というのが定説(?)になっているようですが、それは多くの人が関心を持って「音をよくしよう」としてこなかっただけで、HDMIのAudio伝送そのものに致命的な欠陥があるというわけではありません。「ケーブルが細すぎる」というような意見の他に、「Clockラインが別になっているから、ケーブルを曲げると信号のずれが生じるので、S/PDIFの同軸に比べて音が悪い」という説も出ています。しかし、これは間違いで前回までのS/PDIF編で述べたように、HDMIのAudio伝送はS/PDIFと同じIEC60958のデータフレーム形式が採用され、3組のTMDSペアを使用して水平ブランク期間中に伝送されます。HDMIのクロックラインはシリアル伝送のためのものであり、Audioデータのサンプリングに使用されるI2Sのbitクロックとは役割が異なります。Audio信号のサンプリングクロックは受信後HDMI Receiver Chipによって復元され(Receiver側で独自に水晶発振で生成したクロックと同期させる)、I2S信号やS/PDIF信号としてReceiverから送り出されます。実際のHDMIラインの信号ではエラー発生率を映像信号よりも低く抑えるためにエラー訂正符号が追加されたパケットとしてまとめられた後に伝送されます。HDMIの仕様書ではPixcel Error Rate(画素のErrorが発生する割合)が10のマイナス9乗以下とされていますので、Audio信号の場合はこれよりは良いということでしょうか。これならNetworkやUSBに比べて遜色はありません。となると、「音が悪い」と言われる原因のほとんどはHDMI ReceiverでのACR(Audio Clock Recovery)回路あたりや、DACまわりにあるのではないでしょうか。
次回からはこのあたりについて実験結果などを報告しながら話を進めて行きたいと思います。SACDもi-LinkからだけではなくHDMIからもDSD信号が出力可能になり、対応プレーヤもPioneerなどから発売されるようになりましたのでHDMI経由のDSD信号をWolfson8714に直接入れてSACDをマルチチャンネルで楽しむというようなことにも挑戦しますのでご期待ください。
「(Receiver側で独自に水晶発振で生成したクロックと同期させる)」
と言うことは、下記の説明は間違いということでよろしいでしょうか?
「HDMIリンクではオーディオデータをパケット化して伝送するため、オリジナルのオーディオ
サンプルクロックは伝送されません
HDMIの仕様ではシンク機器におけるオーディオクロックの再生方法は、一意には定めず
設計自由度として残し、ソース機器の送出方法を定義しています
一般にソース機器では、オーディオとビデオのクロックは共通のクロックから生成されます
二つのクロックは同期してるので、ソース機器はTMDSクロックとオーディオクロックの比例
関係を分数で表わし、その比例関係の値をシンク機器に伝送します。
そしてシンク機器は、クロック分周機とクロック逓倍機を使って、TMDSクロックからオーディ
オクロックを再生します
値の関係を詳しく説明すると、オーディオサンプルクロックを128倍したものをN分周したクロ
ックを生成します。このクロック1周期を元のビデオピクセルクロック(TMDSクロック)でカウ
ントします。このカウント値(CTS:CycleTimeStamp)と先のN値が、パケット化された制御デ
ータとしてTMDSデータチャンネル経由でシンク側に伝送されます。
なおCTS値は、時々刻々カウントした結果の値です。特に映像と音声のクロックが非同期な
系では、時間的に若干変動することもあり得ます。
シンク機器の一般的な動作としては、受け取ったCTS値でTMDSクロックを分周します。得ら
れたクロックをオーディオ用のPLLでN逓倍することによって、ソース機器側と同じ128fsのオ
ーディオクロックを再現できます。
また、N値は整数でありかつ、次に示す範囲内に設定する必要があります
128×fs/1500Hz≦N≦128×fs/300Hz
128×fs/1000Hz≒Nという値になることが推奨されています
HDMI仕様書の中には、代表的なビデオフォーマットとオーディオクロックの各種組み合わせ
に対する、CTS値とN値の例が記載されています。」
HDMI 1.3a 7 Audio
7.2 page 100に
「however, it is permitted and possible to devise an audio clock regeneration function that does not take advantage of the N or CTS values passed to the Sink.」と記述があります。
ということで、ラトックさんはdeviseしたのではないでしょうか?
>ラトックさんはdeviseしたのではないでしょうか
意味不明ですが、エスパーします
らとっくさんは一般的なオーディオクロック復元について述べられていると思いました。それは他で説明されていた事と違うので、「(Receiver側で独自に水晶発振で生成したクロックと同期させる)」
の説明が欲しかっただけですが。