音声技術の基礎｜第9回
送信側が一定間隔で音声を送っても、受信側には同じ間隔で到着するとは限りません。この到着タイミングの揺れを吸収する仕組みがジッターバッファです。音の途切れを減らす役割と、待つことで増える遅延を分けて理解します。
1. 遅延とジッターを区別する
遅延は、送ってから届くまでにかかる時間です。ジッターは、その時間の変動に関係します。すべてのパケットが同じだけ遅れる状態と、早く届くもの・遅く届くものが混在する状態は別です。
例えば20 msごとに送ったパケットの到着間隔が15 ms、30 ms、15 msになれば、受信側はその揺れを扱う必要があります。ただし、管理画面に表示されるジッターの値が、単純な最大値と最小値の差とは限りません。測定方法を確認してください。
2. バッファは再生前の待ち時間を設ける
受信側は到着したパケットを短時間ため、音声の時間関係に合わせて再生します。これによって、少し遅れたパケットを待ったり、順序の入れ替わりを扱ったりできます。
しかし、再生期限を過ぎたパケットは音声の復元に使えないことがあります。ネットワーク上では届いていても、利用できない遅着が発生します。この場合、回線の損失率だけを見ていると音の途切れを説明できません。
3. バッファを大きくすればよいとは限らない
待ち時間を増やすと遅着を吸収しやすくなる一方、相手へ音が届くまでの時間が増えます。途切れが減っても、双方が話し始めるタイミングが重なりやすくなるなど、会話のしづらさが残る場合があります。
固定の待ち時間を使う方式と、状況に応じて調整する適応型があります。適応型でもすべての揺れを吸収できるわけではなく、急な変化への追従や上限は実装に依存します。設定名だけでなく、実際の動作を観測します。
待ち時間を評価する前に、片方向音声遅延とRTTの違いを確認し、片方向の値と往復の値を混同しないようにします。
4. 図の時間例を読む
送信時刻が0、20、40 ms、ネットワーク遅延がそれぞれ40、55、45 msなら、到着時刻は40、75、85 msです。80、100、120 msに再生する計画であれば、この3つは期限に間に合います。これは動作を示す仮想例で、実際の端末の初期化手順や推奨設定値ではありません。
3個目が125 msに到着したとすると、120 msの予定には間に合いません。平均遅延が低くても、単発の大きな遅れで音声データを使えなくなることが分かります。
5. 統計は「変動」と「待ち時間」を分けて読む
RTP/RTCPのジッター推定値は、受信間隔の変動を表す指標です。バッファで実際に何秒待ったかを直接示す値ではありません。WebRTCでは、実装が提供するバッファ滞留や補償の統計も確認できます。
表示単位にも注意します。RTCPの値はRTPクロック単位、WebRTCのjitterは秒というように、取得元によって表現が異なります。単位をそろえる前に数値を比較しないでください。具体的な計算は統計の読み方の記事で扱います。
統計の定義や単位は、RTP・RTCP・WebRTC統計の読み方で詳しく整理しています。
6. 調整前に確認すること
- 途切れた時刻と遅着・補償の増加が一致するか確認する。
- 送信元、無線区間、混雑箇所など、揺れの発生源を調べる。
- 変更前後で会話の遅延も測り、途切れだけで評価しない。
- 平常時と混雑時、両方向で同じ試験を行う。
受信側のバッファ調整は対処の一つです。ネットワークの混雑や端末の処理停止が原因なら、その原因への対応も必要になります。
遅着とネットワーク上の欠落を区別するには、パケットロスと補償処理の違いを確認します。変更前後の聞こえ方を評価するときは、MOS・PESQ・POLQAの測定条件もそろえてください。
参考規格・資料
基準音声と実通話の比較、測定位置・方向を整理する際は、Software AGDによる音声品質評価をご覧ください。音声品質の測定範囲と評価方法を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。