しばらく更新を怠っている間に何通かコメントを頂きました。そのコメントに対する回答と併せて今回はAudioデータのサンプリングについてお話したいと思います。
Audioデータは前回お話したようにデータアイランド期間中にPacketの形でSourceからSinkへ送られます。
ちなみに、前回の図30-1ですが、各Sub PacketのStatusバイトの説明が逆になっていました。図を訂正いたしましたので、再度#30を参照してください。上位4bitはR（Ch.2）の、下位4bitはL（Ch.1）の各Statusを示します。「とだしょー」さんからご指摘を頂きました。ありがとうございました。訂正してお詫びいたします。
Audio用の伝送フォーマットのひとつであるI2Sではサンプリングクロックとワードクロック（LRCLK）がデータとセットになっています。I2Sは3本の信号線が必要ですので、S/PDIFでは1本の信号線でデータとクロックを同時に送るためにBi-Phaseという変調方式を採用してデータにクロックを埋め込んでいました。しかし、HDMIのAudio Sample PacketはUSB Audioなどと同様にデータのみで構成されており、一見しただけではサンプリング周波数もbit長もわかりません。しかし、実際にはS/PDIFのChannel Statusと同様に、各Packetに1bitずつ含まれている情報を192個つなぎ合わせるとサンプリングクロックの周波数（fs、C24からC27の4bit）やデータの長さなどがわかります。Audio Sample Packetとは別にAudio Info PacketというのもSourceから送られてきますが、内容は図31-1のようにSpeakerの配置などの情報のみです。また、さらにそれらとは別のACR packet（Audio Clock Regeneration — HDMIの仕様書ではACRをこのように記述していますが、Silicon ImageのデータシートではACRのことをAudio Clock Recoveryと記述しています。） で特定の係数を伝えるというHDMI独自の方法でSource側からSink側へサンプリングクロックの情報を伝えています。
図31-1 Audio Information Packet
まず、Source側ではAudio dataのサンプリングクロックの周波数（fs）を128倍します。CDでは44.1kHzですが、Blu-Rayでは48kHzが主に使用されています。これを128倍したものをNと名前をつけた整数で分周（devide）します。48,000Hz x 128 = 6,144,000（6.144MHz）となりますから、仮にNを6144として割り算を実行すると商は1,000（1kHz）となります。この商をカウンタにプリセットしてPixel Clockをカウントします。要するに商で示される期間（周波数の逆数）はTMDS Clock何個分かということを数えるわけです。仮にTMDS Clockを148.5MHzとすると商は1kHzでしたので、カウント数は148,500個となります。このカウント数のことをCTS（Cycle Time Stamp）値としてN値と共にACR PacketでSinkに伝えます。ACR packetのフォーマットは図31-2を参照してください。
図31-2 Audio Clock Regeneration Packet
HDMIの仕様書ではNとCTSの推奨値を表にしています。よく使われているものだけ抜粋したのが表31-1です。
表31-1 各サンプリングレート、解像度でのN値、CTS値の推奨値（HDMI 1.3a仕様書より抜粋）
基本的に48kHz系はNで分周後、1kHzになるようにNの値が推奨され、44.1kHz系は0.9kHzになるように推奨されています。CTSの値は単純に1kHzか0.9kHzをTMDS Clockの周波数で割ったものです。実際にHDMI Source機器としてSONY PS3やPioneer BDP-LX80ではN,CTSとしてどんな値をACR PacketにSetして送り出しているのか調べてみました。表31-2の値はHDMI receiver LSIとしてSiI9135を使用し、自作のdebuggerでH/WでSetされている N Value, CTS Valueレジスタの値を読みだしたものです。
表31-2 実際に使用されている N値、CTS値 の例。
LX80でBlu-Ray（USAのFry’sでなぜか特価US$18.99で売っていた”i-Robot”）を再生した場合、解像度を1080iまたは1080pに設定するとHDMI 1.3a仕様書の推奨値とおりのN,CTSが使用されていることがわかりました。PS3の場合、Home画面で1080pに設定した場合や、Blu-Ray（”Night Museum”, DTS-HD MAをPS3でLPCM 5.1ch. 24/48kにデコードした場合）を1080p@60で再生した場合は仕様書の148.5/1.001欄の推奨値とおりのN,CTS値が使用されています。映画と同じ1080p@24pモードで再生した場合は、Blue-RayのタイトルによってCTS値が1bitだけ異なります。これはカウンタによる実測値を反映しているためなのかどうかは定かではありませんが、実際に2，3種のHDMI transmitterのFirmwareを調べてみると、LSI内部のカウンタの値がH/WでそのままACR packetにセットされて送信されるものと、packet用の送信Buffer Registerにソフトウェアで固定値をSetしているものがあります。
Sink側では、ACR Packetで受け取ったN,CTS値とTMDSクロックの周波数から逆算してAudio dataのサンプリングクロックの周波数（fs）を算出します。TMDSクロックをCTSの数だけ数えた値をN倍して128で割ればfsが求められます。実際はHDMI Receiver内部のレジスタにH/Wで検出したfs値がSetされていますので、Firmwareで計算する必要はありません。Audio Sample PacketのCh.StatusもCheckしているのかどうか知りませんが、CTS値が多少変動してもfsが”Unknown”になることはほとんどありません。
HDMI Receiverの次段にDACやDIT（S/PDIFコンバータ）を接続するためにはAudio Sample Packetデータに元のサンプリングクロック（fs）と同じ周波数のLRCLK（WCLK）、データを各bitごとにサンプリングするSCLK（BCLK）の二つのクロック信号を追加し、Packetデータを各bitごとのシリアルデータ（SDATA)に変換してI2S信号を生成しなければなりません。さらにそれ以外にDACやDITの内部動作の基準になるMCLKが必要になります。MCLKは通常、fsを256倍したものや512倍したものが使用されます。128倍（128fs）も使用されないことはありませんがfsが一般的によく使用される48kHzや44.1kHzではなく96kHzや192kHzの場合に限られます。HDMIの場合、MCLKとしてTMDS ClockとN,CTS値から生成した128fsを使用できないのかとも思いますが、HDMI 1.3aの仕様書ではMCLKについては何も触れられていませんし、市販されているHDMI Receiver LSIにはその128fsをLSIから取り出すための端子も見当たりません。
しかし、DACやDITから見た場合、MCLKとLRCLKなどの位相は一致している必要があります。HDMI Receiverとして販売されているLSIはAudio Clock用としてMCLK生成用に水晶発振回路を内蔵しています。たとえばSiI9135では28.322MHzの水晶発振子を使用するようにデータシートには記載されており、DAC用のMCLK出力とI2S信号作成用のMCLK入力の倍数（128,256,382,512など）を設定するレジスタがあります。それから推測すると、水晶発振子でMCLKを作り、それをTMDS信号から作成したfsに同期させてI2S出力を作っているのではないかと思いますが正確に実験して確認したわけではありません。
もうひとつ不思議なのがVideoとAudioの同期に関することです。i-Link（IEEE1394）のDV信号やDVD-CAMなどの信号はVideo信号とAudio信号が別々に圧縮されているため、Time Code（Stamp, Cycle Time、上記のCTSもCycle Time Stampですが、フレームの最初から時系列で入っているとは思えず、前のフレームのものかどうか値をCheckするようなことはできないように思われます）のような仕組があり、VideoとAudioの同期を取っていますが、HDMIではVideo信号とAudio信号の共通のClockがTMDS Clockのみですので、どのようにして同期を取っているのか調査中です。Audio CDではSub-Q信号というSub Track（音声が記録されているAudio Trackに並行したTrack）があり、並行するAudio Trackの「そのあたりの位置！」がCD全体の先頭からxx分ｘｘ秒xxにあるのか、曲の先頭からyy分yy秒yyに相当するのかという情報を得ることができます。
Blu-Rayなどの場合はどういう仕組みなのか現在、調査勉強中です。
次回はもう少し、実験を続けながらいろんなPacketについて話をすすめたいと思っています。
いただいたコメントについて
（1）「ほげほげ」さんから、昨年11月13日の記事「#27 HDMIのAudio伝送について その1」についてコメントをいただきました。コメント全文はコメント欄を参照してください。文章の前後関係を調べるために出典を探したのですが、CQ出版刊「Design Wave」2008年 4月号79ページ （「HDMIの基礎知識」柴田修氏執筆）からでしょうか。
ご質問は
——————————————————————
「（Receiver側で独自に水晶発振で生成したクロックと同期させる）」と言うことは、下記の説明は間違いということでよろしいでしょうか？
——————————————————————
ということですが、当該記事の内容は間違いではありません。元のAudio データがサンプリングされたfs（128fs）をどのようにしてSource機器-Sink機器間で伝えるかということを書いているだけです。私の方は、I2S信号を作成する（I2S信号に同期させる）ためのMCLKをSink機器側で生成して、TMDS信号から作成した信号に同期させるということを書いていますので、両方が補完し合うような関係にあると思います。仕様書にはSink側のRegenerationの方法について特に規定はされていませんので話がややこしくなっていると思います。
（2）「とだしょー」さんから2009年1月8日の記事「#30 HDMIのAudio伝送について その4」についてコメントをいただきました。全文はこちらを参照してください。
ご質問は
————————————————————————-
HDMI規格 1.3a 7章Audioで、Figure 7-1において「128*fs」の値をSource DeviceにてN値を用いてDivideしてVideo Clockを用いてCTS値を作っています。
（質問）
この、「128*fs」と言う値はI2SのMCLK値なのでしょうか？
————————————————————————-
fsはAudioデータのサンプリング周波数です。CDでは44.1kHz、DVDやBlu-Ray（一般的なタイトル）では48kHzとして知られているものです。一方MCLKはI2SやS/PDIFの規格とは関係なく、DACやDITのLSIを動作させるための基準クロックです。CDトランスポートなどで外部クロック入力といわれているのはLRCLK（WCLK）でサンプリング周波数と同じものですが、機器内部のPLLでこれを256倍くらいに逓倍し、DITの動作の基準となるMCLKとしています。TMDS ClockとN,CTS値から作った128fsをそのままあるいは2逓倍してDACやDIT用のMCLKとすることもできないことはないと思いますが、途中で止まったりすると、DACやDITをそのたびにReset/初期化しなければならなくなるのが問題と思います。また、現実にHDMI Receiverからは復元した128fsをMCLKとして取り出すことはできません。128fsとしたのは、N値やCTS値をBinaryで作成するにあたって、20bitに収めるなどの理由があったのではないかと思います。
他にも同じ「とだしょー」さんと「ほげほげ」さんから関連したコメントをいただいていますが、上記の回答に含んでいますのでご了承ください。