HDMIでのAudio信号の伝送は、Video信号の合間を縫って行われかつVideo信号と同期しなければなりませんので結構複雑です。同じDigitalとは言え、AudioだけのS/PDIFやI2Sのように簡単ではありません。したがって、しばらくはHDMI仕様書の解説のような記事が続きますが、ご容赦ください。
1. Audio信号はHDMIコネクタ、ケーブルのどこを通過しているのか。
HDMIのコネクタは19の端子があります。Video信号やAudio信号の伝送に直接関係がない信号線として、未使用（#14）、GND（#1）、HPD（#19）、CEC（#13）、DDC関係（#15,16,18）があります。最初にこれらをざっと説明しておきます。
HPDはHot Plug Detectという意味で相手が接続されたことを検出するために使用されます。Sink側（TVなどVideo/Audio信号の受信側）がSource側（BRプレイヤなどの送信側）に通知するためにDC+5Vを出力します。Source側はこの信号の立ち上がり（0Vから+5Vへの変化）を検出して、Sink機器とケーブルが接続されたことを認識します。
DDCはDisplay Data Controlの略で、Sink側の機器がどのような仕様になっているかという情報をSource側が読みだすために使用されます。PCで使用されているDVIやVGAなどの元々の仕様（PC関係のDisplayの団体VESAが決めました）では、これだけですが、HDMIやAV機器ではCEA ExtensionとしてAV関係の仕様を追加しています。たとえばAudio関連では対応しているチャンネル数（スピーカー数）やフォーマット、AudioとVideoのズレ（レイテンシ、リップシンク定数）などがこの部分に含まれています。さらに、HDMIではHDCPのKeyの交換や、後で説明するAudio伝送用のパラメータを受信側のLSIのレジスタに書き込むためなどにも使用されています。特にHDCPのKeyテーブルの交換は定期的（2秒間隔）に行われていますので、入力チャンネルの切り替えなどでこのDDCラインが切れてしまうと再認証まで約10秒ほど掛かります。DDC関係の3本の内訳は、DDC_CLK（クロック）、DDC_DATA（データ）、DDC_Power（Sink機器の電源がOFFの場合でも、情報が読み出せるようにSource機器がSink機器内部のEDID（Enhanced Extended Display Interface Data）回路に電源を供給するためです。Sink機器にとっては、Source機器を検出することにも使用できます）です。
CECというのはViera LinkとかBRAVIA Link, AQOUS Linkなどと呼ばれているリモコン信号をHDMI機器間で共用するための信号線です。電源OFFなどのコマンド仕様は標準化されていますがベンダごとの拡張コマンド仕様も認められていますので、「なんとかLink」が乱立する結果となり消費者にとっては迷惑なことになっています。
これらの信号は低速（100kHz）で、シングルエンド（片側GND、片側+5V）ですので扱いやすく、ケーブルもそれほど気を使わなくとも済みますが、Video/Audio信号を通過させるケーブルは細かい要求仕様が決められており、HDMIの認証試験もあります。認証試験に合格したケーブルしかHDMIロゴマークをつけてはいけないことになっていますが、「いずくも同じ...」で食品と似たような...です。また、HDMIのロゴを付けていても、LANケーブル同様カテゴリによりクラス分けされています。すなわち
Category 1 （TMDS Clock 74.25MHz 以下に使用）
Category 2 （TMDS Clock 74.25MHz 以上に使用）
の2種類があります。したがって、1920x1080p/60Hz（Pixel Clock 148.5MHz）のFull HDにはCategory 2を使用すべきです。1080i/30Hz（Pixel Clock 74.25MHz）までならCategory 1でもOKということになります。ちなみにHDMIケーブル上を流れるTMDS Clockは24bit Colorの場合はPixel Clockと同じ周波数ですが36bitのDeep Colorの場合はPixel Clockは同じ148.5MHz（1080p）ですが、TMDS Clockは1.5倍の周波数（222.75MHz）になりますので、Cat2が必須となります。Cat1とCat2ケーブルでは高速（特にGHz以上）の減衰量が違うだけでなく、TMDS信号（Video/Audio信号、クロック信号）の個別のペア、各ペア相互間のスキュー（信号の時間差）の要求されるレベルが違います。HDMIケーブルを購入される場合はCategory表示に注意してください。私の知る限りではSONYの平たいケーブルはCategory2と表示されていますが、他の製品については知りません。雑誌のHDMIケーブルスクランブルテストレポート記事でもCategoryに関してはあまり注意が払われていないようです。ただし、Cat2のケーブルが「音がいい」、「映像がきれい」と言っているわけではありません。しかし、HDMIの規格上、Categoryを別にした理由は存在しますので購入時にはチェックすべきと思います。
Video/Audio信号の伝送はチャンネル0,1,2という3組の信号と、クロック信号によって行われます。これら4組の信号線は電気的にはLVDS（低電圧差動信号）という方式です。2本の信号線の電圧の差によって信号を伝送しますので、それぞれにD+、D-という2本の信号線があります。一般的にはこれらの2本の信号線を耐ノイズのためにより合わせてツイストペアとしますが、Ghzオーダーとなると線間の容量や信号遅延などの影響が大きくなりますので、その辺は電線メーカのKnowhowとなっています。HDMIではこれらのペアをシールド（導体の網や線、テープなど）で囲んでひとつのチャンネルの信号線としています。さらに3組とクロック（C+、C-、シールド）を他の信号線とまとめてシールドをしています。
チャンネル0,1,2の各信号線は図-1のようにさらにTMDSと呼ばれる方式でエンコードされてトランスミッタからケーブル上に送り出され、Sink機器の入り口のTMDSレシーバに伝えられます。TMDSトランスミッタはエンコードするだけではなく、シリアルデータへの変換、LVDSへのレベル変換も行いますので、TMDSレシーバもそれに対応して受信したデータをデコードして元の形に戻します。
各チャンネルは表-1のように14bitのパラレルデータが割り当てられ、1bitのシリアルデータに変換されてケーブル上を通過します。
Video信号は各チャンネルあたり8bitで、それぞれチャンネルごとにB,R,G（あるいはCb,Cr,Y）が割り当てられていますが、Audioデータは事前にパケット化され、さらにサンプリングデータは4bitずつに分解され、チャンネル1と2で送信されます。AudioデータパケットはS/PDIFやAESと同様、IEC-60958（L-PCM）もしくはIEC61937（Dolby 5.1chなど既存のDVD）に準じてフォーマットされています。L-PCMの場合、S/PDIFではプリアンブル4bit、サンプリングデータ24bit、ステイタス4bitの合計32bitでしたが、HDMIではプリアンブルを省いた28bitとなっています。
パケットフォーマットに関しては後日あらためて説明しますので、そちらを参照してください。
次回はHDMI全体の信号の中にAudio信号がどのように組み込まれて伝送されているのかということについてふれたいと思います。
P.S.）
Bunpeiさんから、かなり前の記事に関するご質問を11月20日に頂きました。元の記事に戻らずに簡単にこの場で回答させていただきます。
頂いたコメントの内容（ご質問のみ転載しています。全文はコメント欄を参照してください）は下記です。
Q.1. （コメント全文はこちら）
I2S入力を受けたDACは普通、自分の内部FIFOかどこかに何点分かのバッファリングをするのではなく、受けたものは即変換してしまう設計でしょうか？それともある程度バッファリングするのが常識なのでしょうか？通常のDACLSIは自分から外部メモリに取りに行くことはしないで、シリアルで流れ込んでくるのを受動的に受けるだけなのでしょうか？
出力の間隔は、I2Sで入力されたLRCLKではなく自分の持つクロックを基に算出して出力すると考えていいでしょうか？
A.1.
ご質問のようにDACは基本的に入力されたDigitalデータを即時にアナログデータに変換して出力します。I2Sのようなシリアル入力が主流ですが、Multi Bitでラダー抵抗で変換することにこだわっている人もいます。DACは基本的にクロックは自分では持たず、入力されたLRCLK（サンプリングクロック）、BCLK（I2Sのようなシリアル入力の場合の各bitのデータサンプリングクロック）を基準に動作します。このうちBCLKはマージン（余裕）がありますので、少々ずれても(Jitterが多くても）影響はありませんが、LRCLKは音楽のテンポに影響しますのでJitter対策などは重要です。
Q.2. （コメント全文はこちら）
Windows XP,Vistaなどのusbaudio.sysの標準ドライバはUSBのIsochronous転送を使用しており、その場合エラー検出時の再送は一切ないという理解でよろしいでしょうか？
一方、御社の製品ではusbaudio.sysを使用せずに独自のドライバで受信機との間で送達確認を行い、エラー検出時には等時性確保の範囲内で再送を試みているという理解で正しいでしょうか？
A.2.
いずれUSB Audio転送について説明する予定ですが、とりあえず簡単に回答いたします。
Isochronous転送は基本的に「送りっぱなし」でAck（受領確認のための返答）はありません。したがって、エラーが発生してもPC側は分かりませんので、再送は行いません。
当社のLink2では、PCとのAudioデータ転送はusbaudio.sysを使用しています。したがってUSB（PCと送信機の間）はIsochronousでエラー発生時の再送要求や再送は行っていませんが、送信機と受信機の間（Wireless）ではバッファを設けて、受信機側でエラーを検出した場合は再送要求を行い、規定時間内に何度か再送するような方法を取っています。
USB AudioではFull Speed（12Mbps）を使用し、1ms間隔でAudioデータ（L-PCMではIEC60958準拠）をIsochronousデータとして定期的に送信します。CDをWAVやAIFFの非圧縮でリッピングしたデータは44.1KHzでサンプリングされていますのでサンプリングデータ数は1秒間に44100個となります。ところが1000で割りきれないため、1msに44個分のサンプルデータを9回続けて送り、10回目に45個のサンプルデータを送信するという苦し紛れの辻褄合わせを行っています。問題はデータ化け（きちんとH/Wが作られていればほとんど発生しません）よりもPC全体のソフトウェアの処理能力によるデータの欠落にあります。Audioデータの転送の基準となる1msのクロックはUSBコントローラがH/Wで管理し、メモリ（エンドポイント）上のデータをDMAで取り出してUSBバス上位に送信します。さらにディスクリプタチェイン（送信するAudioデータの順番と所在をしめす表と考えてください）にしたがって、メインメモリ上にあるメモリブロックからAudioサンプリングデータをDMAで取り出しながら、Audioデータの送信を続けます。ところが、上位のアプリケーションプログラムの処理がモタついて他の処理に追われ、Audioデータが準備されていない場合や、ディスクリプタが更新されていない場合があります。このような場合には同じところを続けて再生したり、Isochronousデータが欠落していることが続けば「ブチッ」という音が聞こえたりします。
一般的に使用されているUSB-DACではPCから1ms間隔で送られてきたAudioデータをFIFOに入れて、そのまま変換しているだけですので、このような問題が生じやすくなります。特にWindows VistaやMacOSX 10.4以降ではUSB Driverが特権モードやカーネルモードからユーザモードに移行したため、こういう問題が多くなったようです。ためしにiTunesでCover FlowをONにして音楽を再生してみてください。OFFのときのほうが問題が少ないと思います。
私の初歩的な質問に対して、正確で丁寧なご回答を頂戴し、心から感謝申し上げます。
私が寄り付いているあるオーディオのブログ
http://audioniravana.blog.ocn.ne.jp/nishinoblog/
で、インフラノイズ社のUSB-101という製品をきっかけにこれまでのアナログ的ピュアオーディオ派の人達がPCオーディオまたはPCトランスポートに切り替えつつあります。よろしければ一度ご覧下さい。また、オーディオ修行という観点から釈迦に説法のいらぬお世話でありますが、
http://shinshu.fm/MHz/06.94/
がおもしろいかと存じます。御社の製品のレファレンス用スピーカとして最適な気がいたしますのですが。
本当にありがとうございました。
投稿情報: Bunpei | 2008年12 月 6日 (土) 14:41
いつも楽しく読ませていただいてます。
usbaudio.sysによるUSB Audio転送についてQ&Aを読んで疑問に思った事があり質問させていただきます。
USB Audio転送における「サンプルレートの指定」はどのように行っているのでしょうか。
どのレートでもデータパケット間隔が1ms固定でパケットデータ長から算出するのか、データパケット間隔も可変してその周期xデータ長からなのか、はたまたパケットのヘッダにレート表記がありそれを参照しているのか、いずれかかと考えているのですが資料が見つけられませんでした。
USB AudioではDACへのクロックを、このデータパケット間隔をてい倍して作っている、最近ではそれに対しPLLを使う事でJitterを低減させているという情報を見かけるので、間隔かデータ長いずれかではないかと思っているのですが…これが本当だとすると御社製品のような無線デバイスはともかく、普通のサウンドデバイスでは高Jitter化は避けられないように思えますがいかがでしょうか。
投稿情報: YH | 2009年10 月14日 (水) 12:31