about://tracing と Audion(Chrome DevTools の WebAudio 拡張機能)を使用して、Chrome で Web Audio アプリのパフォーマンスをプロファイリングする方法について説明します。
このドキュメントにアクセスされたのは、Web Audio API を使用するアプリを開発していて、出力からポップノイズが発生するなどの予期しない不具合が発生したか、予期しない音が聞こえたためだと思われます。すでに crbug.com のディスカッションに参加していて、Chrome エンジニアから「トレースデータ」のアップロードやグラフの可視化の調査を依頼されている場合があります。
関連情報を取得する方法を学び、問題を把握して根本的な問題を解決できるようにします。
Web Audio プロファイリング ツール
Web Audio のプロファイリングに役立つツールは、about://tracing と Chrome DevTools の WebAudio 拡張機能の 2 つです。
about://tracing はどのような場合に使用しますか?
原因不明の「不具合」が発生した場合。トレースツールでアプリをプロファイリングすると、次の情報を得ることができます。
- 異なるスレッドでの特定の関数呼び出しに費やされたタイム スライス
- タイムライン ビューの音声コールバックのタイミング
通常、オーディオ コールバックの期限超過や、予期しないオーディオの不具合を引き起こす可能性のある大規模なガベージ コレクションが表示されます。この情報は根本的な問題を理解するのに役立つため、特にローカルでの再現が難しい場合は、Chromium エンジニアがよく尋ねます。一般的なトレースの手順を確認します。
Web Audio DevTools 拡張機能はどのような場合に使用しますか?
音声グラフを可視化し、音声レンダラのパフォーマンスをリアルタイムでモニタリングする場合。音声グラフ(音声ストリームを生成して合成する AudioNode オブジェクトのネットワーク)は複雑になることが多いですが、グラフ トポロジは設計上不透明です。(Web Audio API には、ノード/グラフのイントロスペクション機能はありません)。グラフに変化があり、無音になります。次に、リスニングによるデバッグを行います。簡単なことではありません。オーディオ グラフが大きくなると、さらに難しくなります。Web Audio DevTools 拡張機能を使用すると、グラフを可視化して確認できます。
この拡張機能を使用すると、レンダリング容量の実行中の推定値をモニタリングできます。これは、特定のレンダリング バジェット(約 2.67 ミリ秒 @ 48 KHz など)でウェブ音声レンダラがどのように動作するかを示します。容量が 100% に近づくと、レンダラが指定された予算内で作業を完了できないため、アプリで不具合が発生する可能性があります。
about://tracing を使用する
最良の結果を得るには、他のタブとウィンドウをすべて閉じ、拡張機能を無効にします。または、Chrome の新しいインスタンスを起動するか、別のリリース チャンネル(ベータ版や Canary など)の他のビルドを使用することもできます。ブラウザの準備ができたら、次の手順を行います。
- タブでアプリケーション(ウェブページ)を開きます。
- 別のタブを開き、
about://tracingに移動します。 - [録画] ボタンを押し、[設定を手動で選択] を選択します。
- [レコード カテゴリ] セクションと [デフォルトで無効になっているカテゴリ] セクションの両方で [なし] ボタンを押します。
- [レコード カテゴリ] セクションで、次の項目を選択します。
audioblink_gcmediav8.execute(AudioWorkletJavaScript コードのパフォーマンスに関心がある場合)webaudio
- [デフォルトで無効になっているカテゴリ] セクションで、次の項目を選択します。
audio-worklet(AudioWorkletスレッドの開始位置を確認する場合)webaudio.audionode(各AudioNodeの詳細なトレースが必要な場合)
- 下部にある [録画] ボタンを押します。
- アプリケーション タブに戻り、問題をトリガーした手順をやり直します。
- 十分なトレースデータが収集されたら、トレース タブに戻り、[停止] を押します。
[トレース] タブに結果が視覚化されます。

[保存] をクリックしてトレースデータを保存します。
トレースデータを分析する方法
トレースデータは、Chrome のウェブ オーディオ エンジンがオーディオをレンダリングする方法を可視化します。レンダラには、オペレーティング システム モードとワークレット モードの 2 つのレンダリング モードがあります。各モードでは異なるスレッド モデルが使用されるため、トレース結果も異なります。
オペレーティング システム モード
オペレーティング システム モードでは、AudioOutputDevice スレッドがすべてのウェブ音声コードを実行します。AudioOutputDevice は、ブラウザの Audio Service から発生し、オーディオ ハードウェア クロックによって駆動されるリアルタイム優先度スレッドです。このレーンのトレースデータに不規則性が見られる場合は、デバイスからのコールバックのタイミングが不安定である可能性があります。Linux と Pulse Audio の組み合わせでは、この問題が発生することがわかっています。
詳しくは、Chromium の問題 #825823、#864463 をご覧ください。

ワークレット モード
AudioOutputDevice から AudioWorklet スレッドに 1 つのスレッドがジャンプする Worklet モードでは、2 つのスレッドレーンに沿ってトレースが適切に配置されているはずです。ワークレットがアクティブになると、すべてのウェブ音声オペレーションが AudioWorklet スレッドによってレンダリングされます。このスレッドはリアルタイムの優先度ではありません。
ここでよく見られる異常は、ガベージ コレクションまたはレンダリングの締め切り超過によって発生する大きなブロックです。どちらの場合も、音声ストリームにグリッチが発生します。

どちらの場合も、理想的なトレースデータは、音声デバイスのコールバック呼び出しとレンダリング タスクが、指定されたレンダリング バジェット内で適切に完了していることで特徴付けられます。2 つのスクリーンショットは、理想的なトレースデータの優れた例です。
実際の例から学ぶ
例 1: レンダリング予算を超えるタスクをレンダリングする
次のスクリーンショット(Chromium の問題 #796330)は、AudioWorkletProcessor のコードの実行に時間がかかりすぎて、指定されたレンダリング予算を超えた場合の典型的な例です。コールバックのタイミングは適切ですが、Web Audio API の音声処理関数呼び出しが、次のデバイス コールバックの前に処理を完了できませんでした。

選択肢:
AudioNodeインスタンスの数を減らして、オーディオ グラフのワークロードを減らします。AudioWorkletProcessorでコードのワークロードを減らします。AudioContextのベース レイテンシを増やします。
例 2: ワークレット スレッドでの大幅なガベージ コレクション
オペレーティング システムの音声レンダリング スレッドとは異なり、ガベージ コレクションはワークレット スレッドで管理されます。つまり、コードでメモリ割り当て/割り当て解除(新しい配列など)を行うと、最終的にガベージ コレクションがトリガーされ、スレッドが同期的にブロックされます。Web Audio オペレーションとガベージ コレクションのワークロードが特定のレンダリング バジェットよりも大きい場合、音声ストリームにグリッチが発生します。次のスクリーンショットは、このケースの極端な例です。

選択肢:
- メモリを事前に割り当て、可能な限り再利用します。
SharedArrayBufferに基づいて異なる設計パターンを使用します。これは完璧なソリューションではありませんが、いくつかの Web Audio アプリでは、SharedArrayBufferを使用して集中的なオーディオ コードを実行する同様のパターンが使用されています。例:
例 3: AudioOutputDevice からのジッターのあるオーディオ機器コールバック
ウェブ オーディオでは、オーディオ コールバックの正確なタイミングが最も重要です。これは、システム内で最も正確なクロックである必要があります。オペレーティング システムまたはそのオーディオ サブシステムが確実なコールバック タイミングを保証できない場合、後続のすべてのオペレーションが影響を受けます。次の画像は、ジッターのある音声コールバックの例です。前の 2 つの画像と比較すると、各コールバックの間隔が大幅に異なります。

選択肢:
latencyHintオプションを調整して、システム オーディオ コールバック バッファのサイズを増やします。- 問題が見つかった場合は、トレースデータとともに crbug.com で問題を報告してください。
Web Audio DevTools 拡張機能を使用する
Web Audio API 専用に設計された DevTools 拡張機能を使用することもできます。トレースツールとは異なり、グラフとパフォーマンス指標をリアルタイムで検査できます。
この拡張機能は Chrome ウェブストアからインストールする必要があります。
インストール後、Chrome DevTools を開いて上部のメニューの [Web Audio] をクリックすると、パネルにアクセスできます。

Web Audio パネルには、コンテキスト セレクタ、プロパティ インスペクタ、グラフ ビジュアライザー、パフォーマンス モニタの 4 つのコンポーネントがあります。
![Chrome DevTools の [Web Audio] パネルのスクリーンショット。](https://web.dev/static/articles/profiling-web-audio-apps-in-chrome/image/screenshot-the-web-audio-08a69d45a077a.png?authuser=0&hl=ja)
コンテキスト選択ツール
1 つのページに複数の BaseAudioContext オブジェクトが存在する場合があるため、このプルダウン メニューで検査するコンテキストを選択できます。左側のゴミ箱アイコンをクリックして、ガベージ コレクションを手動でトリガーすることもできます。
プロパティ インスペクタ
サイドパネルには、ユーザーが選択したコンテキストまたは AudioNode のさまざまなプロパティが表示されます。AudioParam での動的値の検査はサポートされていません。
グラフ ビジュアライザー
このビューには、ユーザーが選択したコンテキストの現在のグラフ トポロジが表示されます。この可視化はリアルタイムで動的に変化します。可視化の要素をクリックすると、プロパティ インスペクタで詳細情報を確認できます。
パフォーマンス モニター
下部のステータスバーは、選択した BaseAudioContext がリアルタイムで実行される AudioContext の場合にのみ有効になります。このバーは、選択した AudioContext の音声ストリームの瞬時品質を示し、1 秒ごとに更新されます。次の情報が提供されます。
コールバック間隔(ミリ秒): コールバック間隔の加重平均または分散が表示されます。理想的には、平均値は安定しており、分散はゼロに近い値になります。分散が大きい場合は、システムレベルの音声コールバック関数のタイミングが不安定で、音声ストリームの品質が低下する可能性があることを意味します。(例 3 を参照)。
レンダリング容量(%): 容量が 100% に近づくと、レンダラが特定のレンダリング予算に対して処理しすぎていることを意味します。そのため、処理を減らす(グラフ内の
AudioNodesオブジェクトの数を減らすなど)ことを検討する必要があります。
ゴミ箱アイコンをクリックすると、ガベージ コレクタを手動でトリガーできます。
以前の WebAudio DevTools パネル
この拡張機能は Chrome Web Audio チームが推奨する方法ですが、以前の WebAudio DevTools パネルも利用できます。このパネルにアクセスするには、DevTools の右上にある「その他」メニューをクリックし、[その他のツール]、[WebAudio] の順に移動します。

まとめ
音声のデバッグは困難です。ブラウザでの音声のデバッグはさらに困難です。ただし、これらのツールを使用すると、ウェブ音声コードのパフォーマンスに関する有用な分析情報を取得できるため、問題を軽減できます。ただし、Chrome または拡張機能に問題が見つかることもあります。crbug.com でバグを報告するか、拡張機能の公開バグトラッカーでバグを報告します。