ブラウザゲームの音が遅れる原因は？Web Audioの遅延と効果音の設計

1. baseLatencyとoutputLatencyは同じ値ではない

MDNではbaseLatencyを、AudioContextの出力がホストの音声系へ渡るまでの処理遅延として説明しています。outputLatencyは、そこから出力装置で処理されるまでの遅延の推定値です。latencyHintを指定しても、ブラウザがその希望を採用するとは限りません。表示された値を操作から聞こえるまでの全遅延と考えないようにします。

ゲーム内には入力を受けるまでの時間、音の再生を指示するまでの処理、画像の更新、音の出力などがあります。まず「ボタンの表示はすぐ変わるのに音だけ遅い」「画面も音も遅い」を分けて観察します。原因が読み込みなら素材準備、計算なら処理の分担、出力装置なら確認環境の整理と、調べる入口が変わります。

const audio = new AudioContext({ latencyHint: 'interactive' });
const reported = {
  baseSeconds: audio.baseLatency,
  outputSeconds: typeof audio.outputLatency === 'number'
    ? audio.outputLatency : null
};
// APIの報告値。入力から耳に届くまでの実測値ではない。

2. 短い効果音は、操作の前に準備を終える

MDNのAudioBufferSourceNode資料では、メモリにあるAudioBufferを再生する仕組みが説明されています。一つのsource nodeは一度の再生に使い、同じbufferは繰り返し利用できます。素材データの準備と、一回ごとの再生ノードを作る処理を分けて管理します。

この記事の提案は、決定音やジャンプ音を最初のステージの準備に含めることです。操作の瞬間に音声ファイルを取得する構成では、通信状況によって反応が変わります。短い効果音は事前に準備し、利用者の操作で音を開始できる状態になった後、必要なノードを作って再生します。長いBGMもすべて同じ形でメモリに置くかは、素材量を見て別に判断します。

音を出す処理は一箇所にまとめると、音量、重なり数、連続再生の制御をそろえられます。同じ操作を短時間に繰り返したとき、全部の音を重ねるのか、直前の音を残すのかを演出として決めます。音を重ねすぎたことによる聞きづらさを、単純な遅延の問題と混同しないようにしましょう。

3. 予定した音と、今すぐ鳴らす音を分ける

操作の確認音は入力に近いタイミングが必要ですが、BGMに合わせる演出は一定の音の時間軸を使う設計が候補になります。この記事では、すぐ鳴らす効果音と、先の時刻に予定する演出を別の窓口にする方法を提案します。処理が遅れた後に古い音をまとめて鳴らす構成は、画面の状態と合わなくなるため避けたい挙動です。

予定した音をキャンセルする条件も決めます。ステージ終了、ミュートへの切り替え、再挑戦の開始で、前の状態の音が残らないようにします。音を消していても、重要な操作の結果は画面で分かるようにします。音のタイミングを改善する作業が、音を使えない利用者の操作を妨げない形にしましょう。

• 効果音の準備完了前にプレイを始めない
• 連続操作で重ねる音の数を決める
• 再挑戦で前の音の予定を片付ける
• ミュートでも成功や失敗を読める表示にする

4. APIの推定値と、感じた遅れを別々に記録する

確認記録には端末、ブラウザ、出力装置、有線や無線の区別、確認した場面を書きます。APIの値が取得できない場合は未取得のまま残し、ゼロとして扱わないようにします。outputLatencyの対応が広がっていても、古い環境や使う装置によって条件は変わるため、表示する前にプロパティを確認します。

「操作に遅れて聞こえた」という観察と、正確な測定結果は分けます。ここでは測定機器を使った検証を行っていません。作品で校正機能を用意する場合は、利用者が調整値を戻せること、装置を変えたときに見直せることも設計します。必要な操作の反応を確かめた上で、BGMや装飾音を増やすと、どの変更で問題が起きたか追いやすくなります。

確認用の画面には、一つの操作で見た目を変えて短い音を鳴らす経路を置けます。連打や長いBGMを外し、単純な条件で違いを見るための画面です。その画面で問題が出ない場合は、実際のステージの計算や連続した音の処理を追加して比べます。何を増やした段階で反応が変わったかを残すと、音声APIの変更が必要なのか、ゲーム処理の見直しが先なのかを判断しやすくなります。