波形は正常なのに、なぜ一定周期で音が消えるのか

2026-10-05

AES67とST2110-30、ptime（パケット時間）不一致という盲点

中継車の中で、ミキサーのメーターは正しく振れていた。ネットワークスイッチのポートランプにもエラー表示はない。それなのに、送出されている音声だけが、ほぼ同じ間隔で「プツ、プツ」と欠ける。ケーブルを挿し直し、スイッチを再起動し、最後にはミキサー本体を疑って予備機に差し替えた。症状は消えなかった。あとになって分かったことだが、疑うべき場所はケーブルでもミキサーでもなく、音声をIPパケットに切り分ける際の「刻み方」そのものにあった。

AES67やSMPTE ST2110-30は、音声をひとかたまりのデータとして送るのではなく、一定時間ごとに細かく分割したパケットとして送り出す。この分割の単位時間を「ptime(パケット時間)」と呼ぶ。サンプリング周波数48kHzの場合、ptimeが125マイクロ秒ならパケット1個あたり6サンプル、250マイクロ秒なら12サンプル、333マイクロ秒なら16サンプル、1ミリ秒なら48サンプル、4ミリ秒なら192サンプルを運ぶ(AIMS Alliance「AES67-101: The Basics of AES67」2018年版のRTPパケット時間規定表による)。そしてAES67の規格が受信側に必須として課しているのは、この中の「1ミリ秒・1〜8チャンネル・48kHz・24bit」というただ1系統だけだ(同資料)。ST2110-30側も、Level A(1ミリ秒・1〜8ch)、Level B(0.125ミリ秒・1〜8ch)、Level C(0.125ミリ秒・1〜64ch)という3段階に分かれている(同資料)。つまり「AES67対応」「ST2110-30対応」という表記だけでは、実際にどの刻みでパケットが飛んでくるかは決まらない。

これは、高速道路の料金所に似ている。ETCレーンが「1台ずつ、1秒間隔」で通過する前提で設計されているのに、実際には「8台まとめて、8秒に1回」という固まりでやってくる車列があったとする。通過する車の総数は変わらない。だが、ゲートの処理リズムは前提と食い違ったまま動き続け、いつか必ず破綻する。ptimeの不一致もこれと同じだ。運ばれている音の情報量そのものは正しいのに、届くリズムの単位が想定と違うため、受信側の処理系だけが噛み合わなくなる。だからオペレーターは「音はちゃんと届いているはずなのに」と混乱する。それは操作の未熟さではない。単位が噛み合っていないという、設計段階の話だ。

この食い違いを見つける方法は存在する。SDP(Session Description Protocol)という、送受信の間で交わされる設定情報の中に、”a=ptime”というたった1行がある。この値を送信側と受信側で照合し、一致させる手順を踏めば、周期的な音切れの大半は解消できる。ただし、周期的な音切れを生む要因はptime不一致だけではない。少なくとも他に2系統あり、それぞれ現れ方の周期が違う。この3系統を切り分けて診断する手順を、このあとに書く。