マイク・スピーカーのオーディオ遅延(Latency)測定

2026-04-13公開 8分で読了

要約 (TL;DR)

長く使っていたUSBマイクインターフェースでアコースティックギターを録音するとき、モニターヘッドフォンで約35msの往復遅延が聴こえていた環境を、MOTU M2とASIOドライバの組み合わせに変えたら5ms台まで落ちて、同じ演奏が「演奏不能」から「自然」に瞬時に変わった。「マイクに音を出したのにイヤフォンで少し遅れて聴こえる」現象はバグではなく、往復遅延(round-trip latency)が実在するという物理的証拠だ。遅延は大きく5段階の和で構成される。マイクがサンプリングされた信号を入力バッファに積む時間、DAWや通信ソフトウェアがこれを処理する時間、結果を出力バッファに再び積む時間、DACがこれをアナログに変換する時間、そしてスピーカーから耳までの物理伝播時間(34cmあたり約1ms)。この5項目のうち大半のチューニング余地はバッファサイズとドライバモデルにある。ASIO・WASAPI Exclusive・Core Audio・JACKはそれぞれ典型的な最低遅延が異なり、プラットフォーム制約も違う。本稿は遅延の構成要素、サンプルレート・バッファサイズのトレードオフ、ドライバ別の特性、そしてループバックケーブル + テストトーン + オーディオソフトで実際の往復遅延を測定する手順を整理する。

背景・コンセプト

マイクの音がスピーカーに戻ってくるまでにコンピュータ内部で通る区間は思ったより長い。まずADC(アナログ-デジタル変換器)がマイク信号を一定のサンプルレート(例:48 kHz)でサンプリングし、サンプルを集めて入力バッファに入れる。バッファが1かたまり(例:128サンプル)だけ満ちた時点でドライバがソフトウェアに信号を渡す。ここまでが入力遅延だ。128サンプル / 48 kHzは約2.67msなので、それ自体だけでも意味のある時間が流れる。

ソフトウェア(例:DAW、通信アプリ)は受け取ったバッファに処理(エフェクト、ミックス、ネットワーク送信準備など)を適用し、結果を出力バッファに書く。出力バッファが満ちたかたまりはDACを通してアナログに変換されスピーカーに出る。出力バッファ時間も同じやり方で計算される。

最後に空気中の伝播。音速は常温で約343 m/sなので34cmあたり約1msの遅延が追加される。ヘッドフォンはこの区間がほとんどない一方、部屋の向こう側のモニタースピーカーは数msを足す。1.7m離れたモニタースピーカーペアの前に座って録音するなら、それだけで約5msの追加遅延が出るという意味だ。

往復遅延(round-trip latency, RTT) = 入力バッファ + 処理 + 出力バッファ + DAC/伝播。サンプルレートが同じならバッファサイズを下げるほど遅延は減るが、CPUがより頻繁に起きなければならず負荷が上がる。サンプル単位でバッファを定義する場合、サンプルレートが上がると同じ「サンプル数」バッファが時間としては短くなる効果があるが、高いサンプルレートは処理量が増えてCPU・ドライバ動作に別の形で影響する。

比較・データ

観点ASIOWASAPI ExclusiveCore AudioJACK
プラットフォーム主にWindowsWindows専用macOS専用Linux中心、クロスプラットフォーム対応
典型的最低遅延非常に低い、通常数ms台低い、専用制御で数ms台低い、安定的な数ms台非常に低く設定可能、複雑度あり
共有モードドライバ次第(普通は排他)共有/排他選択可、排他がより低い共有モードが既定だがよくチューニングされているルーティングマトリクス中心、多重クライアント

正確なms数値はハードウェア・ドライバ・OSバージョンで偏差が大きいので、マーケティング文の「1ms遅延」を実値として受けるより、自分の環境でRTTを一度測って基準点を立てる方が実用的だ。Focusrite Scarlett 2i2 3rd GenやMOTU M2のような普及型インターフェースでもASIOまたはCore Audioと組み合わせれば一桁ms領域まで十分降りる。一方、Windows標準WASAPI共有経路やASIO4ALLのような迂回ドライバはハードウェアが同じでも結果が大きく変わるので、「自分のRTT」はハードウェア・ドライバ・バッファの3変数の組み合わせの結果として受け止めるべきだ。

実践シナリオ

シナリオ1 — ライブパフォーマンス・インイヤモニタリング。 ボーカルが自分の声をインイヤで聴きながら歌うとき、RTTが大きくなれば声が数ミリ秒遅れて戻ってきてテンポ感を損ねる。この領域は10ms以下のRTTが目標になり、これのためにバッファサイズを最大限下げ、ASIO/Core Audioのような低遅延ドライバを使い、可能ならインターフェースのハードウェアダイレクトモニタリング機能でソフトウェア経路を迂回する。MOTU M2の前面パネルのモニターノブがこの役割を即座に解決する。

シナリオ2 — ポッドキャスト録音。 同時に複数人が同じ部屋で録音するのではなく各自が自分のマイクだけで録音するなら、50–100ms程度の遅延も許容範囲だ。録音段階では低い遅延が必須ではなく、ポストプロダクションでタイムラインを合わせれば良い。むしろバッファを大きく取ってCPU安定性を確保する方が録音品質に有利な場合が多い。

シナリオ3 — 映像会議。 ブラウザWebRTCベースの会議は平均100–200ms前後の遅延を見せるのが一般的。ネットワーク伝播・エンコーディング・デコーディング遅延が加わるからだ。この水準は会話の自然さを保てる境界近辺で、ワイヤレスイヤフォン・Bluetooth遅延まで加わると会話が被り始める原因になる。

よくある誤解

「Bluetoothは無条件に遅延が大きい」。 クラシックA2DPベースの転送は確かに遅延が大きい。だがLE Audio(LC3コーデック)やaptX Low Latencyのような低遅延コーデックはかなり低い領域まで降りられて、実際の体感が十分に変わる。同じ「Bluetoothイヤフォン」でも対応コーデックによって値が大きく変わる。ただしモニタリング・録音用には依然として有線が安全な選択。

「USBオーディオは常にアナログより良い」。 USBインターフェースが良いDAC・低ノイズプリアンプ・ドライバを備えていればアナログより清潔だが、安いUSB DACはジッタ・ノイズ・ドライバ問題でかえって悪いことがある。「USBだから良い」ではなくコンポーネント品質が先。

「サンプルレート192 kHzなら遅延が低い」。 直感と違って、同じ時間単位(ms)のバッファを維持するならサンプルレートを上げても物理時間は短くならない。サンプル個数でバッファを固定する場合のみサンプルレートが上がってバッファ時間(ms)が短くなり、その代わりCPU負荷とドライバストレスが大きくなる。低遅延設定の核心はサンプルレートではなくバッファサイズとドライバモデルだ。

チェックリスト

  1. 目標RTTを定義する。 ライブ演奏 <10ms、録音 50–100ms、会議 100–200msなど用途別の基準を決める。
  2. ドライバモデルを選ぶ。 WindowsはASIOまたはWASAPI Exclusive、macOSはCore Audio、LinuxはJACK/PipeWire。プラットフォーム既定の共有経路(MME、既定のWASAPI共有モードなど)はたいてい遅延が大きい。
  3. バッファサイズを徐々に減らしてRTTを下げる。 クラックル(dropout)が出る直前までがそのシステムの実戦下限だ。
  4. ループバック測定をする。 インターフェース出力と入力をケーブルで繋ぎ、テストトーンを再生して受け取った波形との時間差をオーディオエディタで読む。
  5. サンプルレートはプロジェクト要求に合わせる。 映像用48 kHz、音楽44.1/48 kHzが無難で、96 kHz以上は明確な理由があるときだけ。
  6. モニタリング経路を点検する。 DAWソフトウェアモニタリングではなくインターフェースのダイレクトモニタリングを使えばRTTをほぼ0にできる。

関連ツール

Patrache Studioの オーディオ遅延測定ツール はブラウザで入力・出力経路の往復遅延を大まかに推定できるよう設計されており、ハードウェア購入なしで現在のシステム状態を把握するのに良い。入力機器全体の遅延を併せて見るなら キーボードのN-Key Rollover(NKRO)とゲーミング入力遅延 を参照し、ビデオ通話のA/V同期問題まで点検するなら ウェブカメラ診断:フレームレート・解像度・照明の相関関係 で扱ったカメラ側遅延要素も併せて合わせるのを勧める。

参考文献

関連ツール

diagno.patrache.studio/audio/latency/