PTPで同期しても音が揺れる理由とバッファ深度の決め方
チャンネル数が増えた瞬間、モニターにプツッという音が混ざった
多局中継の現場だった。PTPグランドマスターはロック状態を示す緑ランプを一日中灯し続け、映像はコマ落ち一つ起こしていない。ところが正午を過ぎ、副音声とガヤマイクの回線を追加で立ち上げた直後から、モニタースピーカーにプツッ、プツッという短いノイズが混ざり始めた。時刻は合っている。クロックは狂っていない。それでも音は、時々かすれる。
PTPが直しているのは「時刻」であって「到着のばらつき」ではない
原因を探るとき、現場がまず確認する場所はPTPのロック状態だ。だがロックしていても症状が消えないなら、疑う場所が違う。PTPが揃えているのは送信側と受信側の「時刻」であって、パケットが実際に届く「タイミングのばらつき」ではない。スイッチのキューに一瞬でも渋滞が起きれば、時刻は正しいままパケットの到着だけが遅れる。この遅れの幅を受け止める余白が「ジッターバッファ」であり、余白が足りなければ、時刻が合っていても音は欠ける。
AES67の仕様では、送信側が守るべきジッターの上限を「パケットタイムの17倍以内」と定め、推奨値としては「パケットタイム1つ分以内」を挙げている（出典：AES67仕様 同期要件）。受信側のバッファはこれを受けて、最低でも「パケットタイムの3倍」、実運用では「パケットタイムの20倍、または20ミリ秒のいずれか小さい方」を確保することが推奨されている（出典：AES67仕様 バッファリング要件）。パケットタイムを1ミリ秒とすれば、推奨バッファは20ミリ秒、最低ラインでも3ミリ秒だ。この数字を知らないまま機材の初期値だけを頼りに本番へ入ると、バッファが最低ラインの3ミリ秒を下回っているかどうかさえ確認しないまま回線を組むことになる。
バスは同じ時刻に出発しても、信号待ちで到着時間はばらつく
PTPで時刻を合わせる作業は、街の全てのバス停の時計を同じ時刻に設定するようなものだ。しかしどのバスも同じ時刻に発車できたとしても、途中の信号待ちや渋滞の具合まではその時計は直してくれない。1台目のバスは5分で着き、2台目は7分かかる。到着時間のばらつきを吸収するために、乗客は「多少早めに待合室で待つ」しかない。ジッターバッファはその待合室であり、待合室が狭すぎれば、遅れて着いたバスの乗客は行き場を失う。それが音の欠落として画面の外に現れる。
原因は3つの場所のどこかにある
同期は取れているのに音が揺れるとき、原因は必ず3つの系統のどこかにある。パケットが通る経路で渋滞が起きる「ネットワーク経路要因」、送受信機材がバッファをどう確保するかという「機材内部要因」、そしてパケットタイムやバッファ深度の設定を現場側が選び切れていない「運用設計要因」だ。この3つ以外に音が揺れる系統は存在しない。どこか一つに絞り込めれば、残り2つは疑わなくてよくなる。
この記事で手に入るもの
有料部を読み終えると、次の3つが手元に揃う。
- AES67・SMPTE ST 2110-30・Danteそれぞれのパケットタイムとバッファ設定の対応表、および現場でどれを選ぶべきかの判断基準
- バッファ深度を計算する式と、実測でジッター量を確認する診断手順（所要時間つき）
- Dante-AES67ゲートウェイのような異なる規格をまたぐ環境で、バッファが二重に積み上がる罠を避ける設計チェックリスト
音を切らさずに届ける現場を見てきた
ジッターバッファは、正しく設定してあるときほど誰にも気づかれない部品だ。だからこそ機材の初期値のまま放置され、チャンネル数が増えた日や回線が長くなった日に、不意打ちのように症状が出る。PTPのロック表示を見て「同期は取れている」と安心した経験は、数えきれないほどある。だが時刻が合っていることと、音が揺れないことは、別の話だ。次の現場でモニターにノイズが混ざる前に、バッファという「待合室」の広さを自分の手で決める方法を渡しておきたい。
コメント