Chrome の 153 で renderSizeHint が追加されたので Web Audio の処理単位によるレイテンシと CPU 使用率の違いを測ってみた
はじめに
ブラウザで楽器や操作音、リアルタイムエフェクトを作っているとき、操作に対するレイテンシを小さくしたくなることが多々あります。しかし、レイテンシにはブラウザ、OS、オーディオ機器など複数の処理が関わっています。ブラウザ内の処理単位を小さくしたとき実際の入出力でどの程度の差になるのか、とか、CPU 使用率がどれだけ変わるのか、などといった疑問が生じますが、仕様だけではなかなか分かりません。
今回の環境では、64 frames を指定すると、128 frames より物理ループバックの往復レイテンシが約 2.90 ms 短くなりました。無負荷時の CPU 使用率は 64 frames の方がやや高く、値を小さくすれば無条件によいわけではありませんでした。 本記事では、Mac と一般的な USB オーディオインターフェースを使い、処理単位ごとの往復レイテンシと CPU 使用率を比較します。その結果から、64、default、hardware のどれを最初に試すか考えます。
renderSizeHint とは
Web Audio は、音声を一定数のフレームにまとめて処理します。このひとまとまりをレンダー量子 (render quantum)、そのフレーム数をレンダー量子サイズと呼びます。
Chrome 153 では、AudioContext の作成時にレンダー量子サイズを要求できる renderSizeHint が追加されました。 整数に加えて、既定の 128 frames を使う default と、現在の構成に応じた値をブラウザへ選ばせる hardware を指定できます。なお、renderSizeHint は、採用を保証する設定値ではなくヒントです。実際の採用値は、AudioContext の renderQuantumSize から確認します。
今回は、これを使ってレンダー量子サイズを変え、物理ループバックの往復レイテンシと CPU 使用率がどう変化するか測りました。
検証環境
- macOS 26.6.2
- Apple M4
- Google Chrome 153.0.8010.37
- RME Babyface Pro FS
対象読者
- macOS 上の Web Audio で、楽器や操作音の反応を短くしたい方
renderSizeHintの指定値と、レイテンシや CPU 使用率の関係を知りたい方- USB オーディオインターフェースを使った測定方法を知りたい方
参考
検証方法
最初に、renderSizeHint へ渡した値と、実際に採用された値を確認しました。
const context = new AudioContext({
renderSizeHint: 64,
});
await context.resume();
console.log({
requested: 64,
actual: context.renderQuantumSize,
});
コンソールには次のように出力されました。
{ requested: 64, actual: 64 }
今回の環境では、指定した 64 frames がそのまま採用されたことを確認できました。
次に、往復レイテンシを測りました。検証用のページを作成してから 5 秒間の信号を出力し、同じオーディオインターフェースの入力へケーブルで戻しました。
無負荷は、信号の出力と入力の録音だけを行い、CPU 使用率を比較するための追加演算を行わない条件です。強い合成負荷では、 Math.sin を繰り返し計算する処理を入れています。
信号には 0.5 秒間隔で 10 個の既知のマーカーを入れています。入力側で録音した信号から各マーカーを正規化相互相関で検出し、出力信号内の配置位置と入力信号内で検出した位置との差の中央値を往復レイテンシとしました。
64、128、256、hardware の 4 種類を、無負荷と強い合成負荷で各 3 回測定しました。(hardware: レンダー量子サイズの選択をブラウザへ任せる指定) 強い合成負荷では、128 frames の処理 1 回につき 100,000 回の反復演算を基準とし、実際の処理単位に比例して 1 回当たりの反復数を変えました。これにより、処理単位が変わっても 1 秒当たりの目標演算量が同程度になるようにしました。
CPU の値は、検証ページを処理する Chrome のレンダラープロセスについて、5 秒間の信号処理とその前後を含む同じ区間の使用率を求めたものです。1 コアを 100% とし、各条件 3 回の平均を使いました。
検証結果
主な結果は次のとおりです。
renderSizeHint |
実測したレンダー量子サイズ | 往復レイテンシ | 無負荷時の CPU | 強負荷時の CPU |
|---|---|---|---|---|
| 64 | 64 frames | 25.69 ms | 15.11% | 42.17% |
| 128 | 128 frames | 28.58 ms | 14.21% | 40.86% |
| 256 | 256 frames | 31.48 ms | 12.69% | 40.89% |
hardware |
128 frames | 28.58 ms | 14.80% | 41.33% |
各条件を 3 回測定したときの集計値は次のとおりです。
renderSizeHint |
負荷 | 実測したレンダー量子サイズ | 往復レイテンシ | Chrome レンダラー CPU |
|---|---|---|---|---|
| 64 | 無負荷 | 64 frames | 25.69 ms | 15.11% (14.19〜15.91%) |
| 64 | 強い合成負荷 | 64 frames | 25.69 ms | 42.17% (41.63〜42.59%) |
| 128 | 無負荷 | 128 frames | 28.58 ms | 14.21% (13.48〜14.84%) |
| 128 | 強い合成負荷 | 128 frames | 28.58 ms | 40.86% (39.90〜42.27%) |
| 256 | 無負荷 | 256 frames | 31.48 ms | 12.69% (12.07〜13.79%) |
| 256 | 強い合成負荷 | 256 frames | 31.48 ms | 40.89% (40.15〜41.51%) |
hardware |
無負荷 | 128 frames | 28.58 ms | 14.80% (14.35〜15.55%) |
hardware |
強い合成負荷 | 128 frames | 28.58 ms | 41.33% (40.35〜41.87%) |
分かったこと
今回の環境では、64、128、256 の整数指定が実際のレンダー量子サイズへ反映されました。hardware でもブラウザが選択した値を取得できました。指定値と採用値を分けて確認できることが分かりました。
同じ入出力経路では、処理単位が小さい条件ほど物理ループバックの往復レイテンシも短くなりました。短い順に 64、128、256 frames となりました。
レンダー量子サイズを 64、128、256 frames と大きくするにつれ、無負荷時の CPU 使用率は低くなりました。強い合成負荷では、処理単位の大きさに沿った CPU 使用率の増減は確認できませんでした。
考察
処理単位の時間差だけで往復レイテンシの差を説明できないのは、往復経路に Web Audio、Chrome と macOS 間の処理、出力、アナログ経路、入力が含まれるためだと思います。また、無負荷時に処理単位が小さいほど CPU 使用率が高かったのは、AudioWorklet の呼び出し回数が増えた影響ではないかと思います。実際のアプリケーションでは平均値だけでなく、AudioWorklet の処理時間や音の状態も確認するのがよさそうです。
レイテンシを優先する楽器やリアルタイムエフェクトでは、まず 64 を候補にするのがよさそうです。今回観測した差が処理の余裕との交換に見合うかは、アプリケーションごとに判断する必要があるでしょう。
従来の既定値を維持したい場合は、renderSizeHint を省略するか default を指定する方法が分かりやすいと思います。128 frames を明示的に要求する理由がある場合は、整数の 128 が候補になると考えています。どちらの場合も、指定値だけを前提にせず、renderQuantumSize を確認するのがよさそうです。
まとめ
Chrome 153 の renderSizeHint について、64、128、256、hardware を指定した場合の採用値、往復レイテンシ、CPU 使用率を確認しました。renderSizeHint は希望値であるため、実装では renderQuantumSize に採用された値を使う必要があります。まずは用途に合わせて 64、default、hardware から候補を選び、renderQuantumSize の採用値と実際の処理の余裕を対象端末で確認するのがよさそうです。本記事が、Web Audio の処理単位を選ぶ際の判断材料になれば幸いです。
