96 kHzのASIOインターフェースで測定した往復レイテンシは、64サンプルのバッファの2.30 msから1,024サンプルの12.30 msへと上昇した(MathWorks、Measure Audio Latencyの例)。最大の設定は、デジタル楽器に長らく推奨されてきた10 ms未満という目標(WesselとWright 2002)を超えることになる。人間の知覚はこの指針よりも複雑だ。2024年のキー押下の研究では、気づく最小の追加レイテンシの平均は48.8 msだった(Schmidほか、Audio Mostly 2024)が、手拍子の二重奏はすでに片道遅延11.5 msを超えるあたりからテンポを保てなくなり始めた(ChafeとGurevich、AES 117th Convention 2004)。このまとめは販売ではなくレイテンシと性能を扱うため、売上やユーザー数については当社のDAW市場統計をご覧ください。Microsoft Learn、Android Compatibility Definition Document、MathWorks、Scan Pro Audio、Audio Engineering Society、NIME、Music Perception、PLoS One、PNASをはじめ、十数件の一次情報源からデータを集約した。
主なポイント
- 96 kHzのASIOインターフェースで、往復レイテンシは64サンプルのバッファで2.30 ms、1,024サンプルで12.30 msだった(MathWorks、Measure Audio Latencyの例)。
- 気づく最小の追加レイテンシの平均は、基準0 msからでは48.8 msだったが、基準64 msの上ではわずか27.1 msだった(Schmidほか、Audio Mostly 2024)。
- パーカッション奏者とアマチュアは、0 msを20 msとジッターのある10 msよりも高く評価したが、安定した10 msよりは高く評価しなかった(Jackほか、Music Perception 2018)。
- 200 msの遅延聴覚フィードバックにより、発話速度は毎秒5.2音節から4.3音節に低下した(OzkerとHagoort、PLoS One 2025)。
- 手拍子の二重奏は片道遅延11.5 msで最もテンポを保ち、演奏の85%は14 ms以上で遅くなった(ChafeとGurevich、AES 2004)。
- ピアノの二重奏は、追加レイテンシ10 msで速くなり、20 msで安定し、40 msで遅くなった(Washburnほか、Frontiers in Psychology 2021)。
- Ryzen 9 9950Xは、64サンプルのバッファで2,140のソフトウェア音源ボイスを、512サンプルで8,580ボイスを処理したが、プラグインのインスタンス数は482から618にしか増えなかった(Scan Pro Audio、DAWBench)。
- Windows 10はオーディオエンジンのレンダリングレイテンシを、浮動小数点アプリの約12 msから1.3 msに短縮した(Microsoft Learn、Low Latency Audio)。
- Androidのプロ向けオーディオ機器は、往復25 ms以下、アナログ経路では20 ms以下を満たさなければならない(Android 16 Compatibility Definition Document)。
- Bluetooth LEのコントローラー接続は操作から音が出るまで平均139 msだったのに対し、組み込みプラットフォームのBelaは約0.6 msだった(McPhersonほか、NIME 2016)。
- パフォーマンスを損なわないため、インイヤーモニターのレイテンシは5 ms以下が推奨されている(Shure Insights 2016、メーカーのガイダンス)。
1. レイテンシ知覚:音楽家が気づく遅延の大きさ
唯一の魔法の数値は存在しない。レーゲンスブルクの弁別閾の研究では、気づく最小の追加レイテンシの平均は、基準がゼロの場合は48.8 msだったが、基準64 msの上ではわずか27.1 msだった(Schmidほか、Audio Mostly 2024)。弁別閾(JND)とは、聴き手が確実に検出できる最小の追加遅延であって、快適に演奏できる遅延ではない。この結果は、すでに遅れているシステムでは、さらなる遅延のほうが気づきやすくなり、気づきにくくなることはないことを示している。
演奏テストは、検出テストよりも低い水準を示す。Jackほか(Music Perception 2018)では、プロのパーカッション奏者とアマチュア音楽家は、安定した10 msをゼロより悪いと評価できなかったが、20 msと、±3 msで揺れる10 msの遅延を低い品質と評価した。バッファ設定にとっての要点は、一貫性が数値そのものと同じくらい重要だということだ。安定した小さなバッファは、ときどき伸びるバッファに勝る。
| 指標 | 値 | 出典 |
|---|---|---|
| キー押下課題で、基準レイテンシ0 msから気づく最小の追加レイテンシの平均 | 48.8 ms(標準偏差33.0、個人差の範囲は10〜129 ms) | Schmidほか、Audio Mostly 2024 |
| 基準レイテンシ64 msから気づく最小の追加レイテンシの平均 | 27.1 ms(標準偏差17.0) | Schmidほか、Audio Mostly 2024 |
| 基準レイテンシ512 msから気づく最小の追加レイテンシの平均 | 77.1 ms(標準偏差57.6) | Schmidほか、Audio Mostly 2024 |
| 音楽的洗練度(Gold-MSIスコア)と気づく最小レイテンシの相関 | r(32) = -0.345、p = 0.046 | Schmidほか、Audio Mostly 2024 |
| 0 msの品質評価と、10 ms、±3 msのジッターを伴う10 ms、20 msとの比較 | ジッターのある10 msと20 msより高い。安定した10 msよりは高くない | Jackほか、Music Perception 2018 |
| デジタル楽器に推奨されるレイテンシの目標 | 10 ms未満 | WesselとWright 2002、McPhersonほか(NIME 2016)に引用 |
| ライブ演奏者に許容されるレイテンシ(楽器とモニタリング構成による) | 1.4 msから42 ms | LesterとBoley、AES Convention Paper 7198、2007 |
補足:負の相関は、音楽的訓練を積んだ参加者ほど、より小さな遅延を検出したことを意味する。演奏者の許容範囲と設計目標について入手できる最新のデータは、LesterとBoley(AES、2007)およびWesselとWright(2002)のものだ。どちらについても、より新しい査読付きの再現研究は見つからなかった。
2. 自分の声が遅れて聞こえる:発話とボーカルモニタリング
声は、話者が骨伝導によっても即座に聞くため、遅延に最も寛容でない信号だ。遅延聴覚フィードバック(DAF)、つまり自分の声がヘッドホンから遅れて再生されるのを聞く現象の研究では、妨害の基準として200 msが使われる。40人の話者は、200 msの遅延の下で発話速度が毎秒5.2音節から4.3音節に低下した(OzkerとHagoort、PLoS One 2025)。これはどんな妥当なDAWのバッファよりもはるかに大きいが、その仕組みを明らかにしている。脳は自分自身の音声をタイミングの基準として使っており、遅れたコピーが本物と競合するのだ。
感受性は人によって大きく異なる。40人の参加者のうち、遅延フィードバックとピッチシフトされたフィードバックの両方に強く反応したのは3人だけで、2026年のPNAS研究は、その抵抗力を、脳内の言語経路である右弓状束の構造と結びつけた。処理された声をリアルタイムでモニタリングする人にとって、それがDAW内のボーカルチェーンであれ、配信向けのリアルタイムボイスエフェクトであれ、この個人差は、なぜある演奏者は気にしない遅延が別の演奏者を混乱させるのかを説明する。インイヤーモニターは歌手にとって一般的な解決策だが、騒音曝露というトレードオフを伴う。これについては当社の音楽家の難聴統計で扱っている。
| 指標 | 値 | 出典 |
|---|---|---|
| 即時フィードバックと200 ms遅延フィードバックでの発話速度(40人の話者が文を朗読) | 毎秒5.2音節と4.3音節 | OzkerとHagoort、PLoS One 2025 |
| 即時フィードバックと200 ms遅延フィードバックでの声の大きさ | 58.2 dBと59.7 dB | OzkerとHagoort、PLoS One 2025 |
| 遅延フィードバック、ピッチシフトフィードバック、その両方に強く反応した話者 | 40人中10人、40人中10人、40人中3人 | OzkerとHagoort、PLoS One 2025 |
| 即時フィードバックと200 ms遅延フィードバックでの発話単語の平均長(30人の話者) | 0.85 sと0.95 s(t = 7.859、P < 0.001) | Ozkerほか、PNAS 2026 |
| 200 ms遅延での非流暢性を、0、25、50 msの遅延と比較(成人17人) | 2倍から3倍多い | Stuartほか、JASA 2002 |
| パフォーマンスを損なわないために推奨されるインイヤーモニターのレイテンシ | 5 ms以下 | Shure Insights 2016(メーカーのガイダンス) |
| 遅延が気づかれ始める可能性があるステージモニターのレイテンシ | 10 ms | Shure Insights 2016(メーカーのガイダンス) |
補足:Stuartほか(JASA 2002)は、いくつかの短い遅延(25 msと50 ms)を200 msと比較した、入手できる最新のデータだ。2025年と2026年の研究は200 msのみを試験した。Shureの数値はメーカーのガイダンスであり、管理された研究ではなく、2016年のものだ。
3. 一緒に演奏する:遅延下のアンサンブルのタイミング
アンサンブルのデータは、レイテンシを不快感から測定可能なテンポのずれへと変える。片道遅延11.5 ms未満では手拍子の演奏の74%が速くなり、14 ms以上では85%が遅くなった(ChafeとGurevich、AES 117th Convention 2004)。小さな遅延はテンポを安定させるブレーキのように働き、大きな遅延は奏者が振り払えない足かせになる。
2021年のピアノ二重奏の研究は、実際の楽器でも同じ方向を示している。ペアは10 msで速くなり、20 msで安定し、40 msで次第に遅くなった(Washburnほか、Frontiers in Psychology 2021)。先行研究のレビューでは、安定した同期は10〜25 ms、全般的な悪化は60 msを超える領域とされている。DAWを通したモニタリングは、部屋の音響的な距離の上にバッファのレイテンシを加えるため、これらの範囲はインターネットセッションだけでなく、トラッキングセッションにとっても重要だ。
| 指標 | 値 | 出典 |
|---|---|---|
| 手拍子の二重奏で試験した片道遅延の範囲(15組を分析、173試行) | 0〜77 ms | ChafeとGurevich、AES 117th Convention 2004 |
| 平均テンポが速くも遅くもならなかった片道遅延 | 11.5 ms | ChafeとGurevich、AES 117th Convention 2004 |
| 11.5 ms未満の遅延で速くなった演奏と、14 ms以上で遅くなった演奏 | 74%と85% | ChafeとGurevich、AES 117th Convention 2004 |
| 追加レイテンシ10、20、40 msでのピアノ二重奏のテンポ(12ペア) | 10 msで速くなり、20 msで安定、40 msで遅くなった | Washburnほか、Frontiers in Psychology 2021 |
| 追加レイテンシで説明される集団テンポの変動の割合 | R² = 0.88 | Washburnほか、Frontiers in Psychology 2021 |
| 先行研究のレイテンシ範囲:同期演奏、テンポ低下、全般的な悪化 | 10〜25 ms、25〜60 ms、60 ms超 | Washburnほか、Frontiers in Psychology 2021(先行研究のレビュー) |
| ネットワーク音楽演奏で引用される典型的なインターネットレイテンシの範囲 | 20〜100 ms | Washburnほか 2021、Cáceresほか 2008とCáceresとChafe 2010を引用 |
補足:ChafeとGurevich(2004)は、11.5 msの最適点について入手できる最新のデータだ。2021年の二重奏の研究はこれと整合するが、遅延の刻み幅が異なっていた。
4. バッファサイズと往復レイテンシ
バッファサイズは下限を決めるが、全体の請求額ではない。ASIOのMADIface USBインターフェースを96 kHzで用いたMathWorksのループバック測定では、往復レイテンシは64サンプルの2.30 msから1,024サンプルの12.30 msに上昇した。バッファが16倍になっても、レイテンシは約5.3倍(12.30 / 2.30 = 5.35)にしかならなかった。遅延の一部がバッファにまったく依存しないためだ。
同じ表から行った当社の計算で、その固定部分が分かる。64サンプルの測定値は221サンプルで、64サンプルのバッファを引くと157サンプルが残る。1,024サンプルの測定値(12.3021 ms × 96 = 1,181サンプル)からも同じく157サンプルが残る。これはコンバーター、ドライバー、転送のオーバーヘッドで約1.64 ms(157 / 96,000)に相当し、どのバッファ設定でも除去できない。したがって、倍にするごとに追加サンプル分の時間が加わるだけだ。96 kHzで64サンプル増えると0.67 msで、64サンプルと128サンプルの行の差とちょうど一致する。
| 指標 | 値 | 出典 |
|---|---|---|
| 測定した往復レイテンシ、64サンプルのバッファ、96 kHz ASIOインターフェース | 2.30 ms(221サンプル) | MathWorks、Measure Audio Latencyの例 |
| 測定した往復レイテンシ、128サンプルと256サンプルのバッファ | 2.97 msと4.30 ms | MathWorks、Measure Audio Latencyの例 |
| 測定した往復レイテンシ、512サンプルのバッファ | 6.97 ms | MathWorks、Measure Audio Latencyの例 |
| 測定した往復レイテンシ、1,024サンプルのバッファ | 12.30 ms | MathWorks、Measure Audio Latencyの例 |
| WindowsのインボックスHDAudioドライバーが対応するバッファ範囲 | 128サンプル(48 kHzで2.66 ms)から480サンプル(48 kHzで10 ms) | Microsoft Learn、Low Latency Audio |
| Android機器が報告する典型的なバッファサイズ | 96、128、160、192、240、256、512フレーム | Android Developers、Audio Latency guide |
| インターフェースが報告するレイテンシの典型的な誤差(AbletonのDriver Error Compensationで補正) | 約±1 msから20 ms | Ableton Help Center、Driver Error Compensation FAQ |
補足:AbletonのDriver Error Compensation FAQは、20 msを超える設定は問題を起こす可能性があり、バッファサイズやサンプルレートが変わるたびに値を再計算する必要があると警告している。平たく言えば、一部のインターフェースは自分自身の遅延を誤って報告するため、DAWに正しい値を伝えないと録音が遅れて配置される。
5. バッファサイズとCPUの余裕
小さなバッファのコストは、CPUが各オーディオの期限までに終えられる処理量に現れる。Scan Pro AudioのDAWBenchソフトウェア音源テスト(RME Babyfaceインターフェースを用いてReaperで実施)では、AMD Ryzen 9 9950Xは64サンプルのバッファで2,140ボイスのポリフォニー、512サンプルで8,580ボイスを維持した。約4.0倍(8,580 / 2,140 = 4.01)だ。プラグインのインスタンステストの伸びははるかに小さく、482から618インスタンスへと28%の増加(618 / 482 = 1.28)にとどまった。
この差が実用上の教訓だ。小さなバッファが最も響くのは大規模なサンプルライブラリ音源で、エフェクトを多用するミックスのチェーンはそれほど影響を受けない。バッファが大きくなるにつれて2つのCPUの優劣も入れ替わる。Ryzen 9 9950XとCore Ultra 7 270K Plusの結果表が示すように、64サンプルではIntelのチップが先行し(プラグインインスタンス512対482)、512サンプルでは両者が618で並んだ。AppleのLogic Proガイドも、それに沿ったワークフローの助言を与えている。最も低いバッファ設定で録音し、システム過負荷の警告が出たときだけ次の段階に上げる。
| 指標 | 値 | 出典 |
|---|---|---|
| DAWBench DSPのプラグインインスタンス数、AMD Ryzen 9 9950X、ASIOバッファ64 / 128 / 256 / 512サンプル | 482 / 562 / 594 / 618 | Scan Pro Audio、3XS Pro DAW Ryzen 9 9950Xのベンチマーク表(販売店が公開) |
| DAWBench VIのポリフォニー、AMD Ryzen 9 9950X、ASIOバッファ64 / 128 / 256 / 512サンプル | 2,140 / 3,780 / 5,660 / 8,580 | Scan Pro Audio、3XS Pro DAW Ryzen 9 9950Xのベンチマーク表(販売店が公開) |
| DAWBench DSPのプラグインインスタンス数、Intel Core Ultra 7 270K Plus、ASIOバッファ64 / 128 / 256 / 512サンプル | 512 / 558 / 583 / 618 | Scan Pro Audio、3XS Project DAW Core Ultra 7 270K Plusのベンチマーク表(販売店が公開) |
| DAWBench VIのポリフォニー、Intel Core Ultra 7 270K Plus、ASIOバッファ64 / 128 / 256 / 512サンプル | 2,380 / 4,080 / 6,380 / 9,260 | Scan Pro Audio、3XS Project DAW Core Ultra 7 270K Plusのベンチマーク表(販売店が公開) |
補足:これらはシステムビルダーが自社の製品ページで公開した表であり、ドライバー、BIOS、Windowsのバージョンの詳細がないため、独立した実験室の結果ではなく目安として扱うこと。
6. OSのオーディオスタック:WindowsとAndroid
DAWの設定が適用される前に、経路上にどれだけのバッファリングがあるかはOSが決めている。Windows 10は共有オーディオエンジンのレンダリングレイテンシを、浮動小数点アプリの約12 msから全アプリで1.3 msに短縮した(Microsoft Learn、Low Latency Audio)。それでも、アプリが明示的により小さい値を要求しない限り、共有モードの既定バッファは約10 msのままだ。この既定値こそが、1999年にSteinbergが作ったドライバーモデルであるASIOが、Windowsの音楽ソフトウェアの標準であり続ける理由だ(Microsoft Windows Music Devブログ、2024年)。その投稿の読者に返信する形で、Microsoftのエンジニアであるピート・ブラウンは、ネイティブスタックでは通常約10 msより低くならないが、ASIOドライバーはしばしば一桁ミリ秒に達すると書いた。
Microsoftの答えは、ASIOインターフェースを備えた新しいインボックスのUSB Audio Class 2ドライバーで、YamahaとQualcommと共同で開発され、公開プレビューはWindows Insider Canaryビルドを通じて2026年に予定されている(Microsoft、Fall 2025 Windows Musician Technology update)。Androidは、どのデスクトップOSよりも明確な合否の数値を公開している。Android 16 Compatibility Definition Documentは機能フラグごとに上限を定めており、Android開発者ガイドは、プロ向けオーディオのフラグが20 msで定義されているにもかかわらず、音楽家は一般に10 msを必要とすると認めている。
| 指標 | 値 | 出典 |
|---|---|---|
| Windows 10以前のWindowsオーディオエンジンのレンダリングレイテンシ、浮動小数点アプリと整数アプリ | 約12 msと約6 ms | Microsoft Learn、Low Latency Audio |
| Windows 10以降のオーディオエンジンのレンダリングレイテンシ | 全アプリで1.3 ms | Microsoft Learn、Low Latency Audio |
| アプリがより小さいバッファを要求しない場合のWindows共有モードの既定バッファ | 約10 ms | Microsoft Learn、Low Latency Audio |
| 低レイテンシ機能を宣言するAndroid機器の連続出力レイテンシ | 45 ms以下 | Android Developers、Audio Latency guide |
| Androidの往復レイテンシ上限、FEATURE_AUDIO_PROを宣言する機器 | 25 ms(アナログ経路では20 ms)、平均絶対偏差5 ms | Android 16 Compatibility Definition Document |
| Androidの往復レイテンシ上限、FEATURE_AUDIO_LOW_LATENCYを宣言する機器 | 50 ms、平均絶対偏差10 ms | Android 16 Compatibility Definition Document |
| Androidのタップからトーンまでのレイテンシ上限、標準的なハンドヘルド機器とプロ向けオーディオ機器 | 250 msと80 ms | Android 16 Compatibility Definition Document |
| Androidのコールド出力とコールド入力のレイテンシ上限、プロ向けオーディオ機器 | それぞれ200 ms | Android 16 Compatibility Definition Document |
補足:平均絶対偏差は、往復の数値が測定ごとにどれだけぶれるかを表し、CDDにおけるジッターの代用指標だ。タップからトーンまでのレイテンシとは、画面に触れてから結果として生じる音が聞こえるまでの遅延である。
7. バッファの手前:コントローラー、MIDI、ワイヤレス接続
完璧なバッファ設定でも、遅いコントローラー経路は救えない。McPherson、Jack、Moroによる2016年のNIME測定では、Bluetooth LEのセンサー接続は、操作から音が出るまで平均139 msで、テストの1%は334 msに達した。一方、組み込みプラットフォームのBelaは約0.6 msを保ち、ジッターは約20マイクロ秒だった。著者らは、テストしたマイクロコントローラーとコンピューターの一般的な構成のうち、受け入れられているレイテンシとジッターの指針を満たしたものはほとんどなかったと結論づけた。
USB MIDIはUSBシリアルより良好だった。Teensyボードが送信するUSB MIDIからMax/MSPへの経路は平均5.1 msだったのに対し、USBシリアル経由のArduino Unoは平均8.2 msで、12%の頻度で10 msを超えた。プロ用のデジタルワイヤレスは別の水準にあり、Shureは自社のULX-Dシステムで約2.9 msとしている。同じ遅延の連鎖という問題はゲーム機器にも通じており、これは当社のゲームのレイテンシ統計が入力遅延とディスプレイについて示している。
| 指標 | 値 | 出典 |
|---|---|---|
| Bluetooth LE(BLEmini)コントローラー接続、操作から音まで | 平均139 ms。テストの1%は334 ms | McPhersonほか、NIME 2016 |
| USBシリアル経由のArduino UnoからMax/MSPへ、最良の場合 | 平均8.2 ms。12%の頻度で10 ms超 | McPhersonほか、NIME 2016 |
| USB MIDI経由のTeensyからMax/MSPへ、最良の構成 | 平均5.1 ms。ジッター1.5 ms | McPhersonほか、NIME 2016 |
| 組み込みプラットフォームBela、アナログセンサー入力からオーディオ出力まで | 約0.6 ms。ジッター約20マイクロ秒 | McPhersonほか、NIME 2016 |
| デジタルワイヤレスマイクシステムのレイテンシ(ULX-D) | 約2.9 ms | Shure Insights 2016(メーカー自身の主張) |
補足:McPhersonほか(2016)は、このコントローラーの並列比較について入手できる最新のデータだ。ここでのジッターとは、最短と最長の遅延の幅を指し、第1節で示したように平均と同じくらい重要である。
数字で見るDAWのバッファサイズと処理レイテンシ(まとめ)
| 指標 | 値 | 出典 |
|---|---|---|
| 64サンプルと1,024サンプルのバッファでの往復レイテンシ、96 kHz ASIOインターフェース | 2.30 msと12.30 ms | MathWorks、Measure Audio Latencyの例 |
| 基準0 msから気づく最小の追加レイテンシの平均 | 48.8 ms | Schmidほか、Audio Mostly 2024 |
| 基準64 msから気づく最小の追加レイテンシの平均 | 27.1 ms | Schmidほか、Audio Mostly 2024 |
| 品質評価:安定した10 msとゼロレイテンシ | ゼロより低くは評価されなかった | Jackほか、Music Perception 2018 |
| ライブ演奏者に許容されるレイテンシ(楽器とモニタリング別) | 1.4 msから42 ms | LesterとBoley、AES Convention Paper 7198、2007 |
| 即時フィードバックと200 ms遅延フィードバックでの発話速度 | 毎秒5.2音節と4.3音節 | OzkerとHagoort、PLoS One 2025 |
| 200 ms遅延と、より短い遅延での非流暢性 | 2倍から3倍多い | Stuartほか、JASA 2002 |
| アンサンブルのテンポの最適点(片道遅延)と、14 ms以上で遅くなった演奏の割合 | 11.5 ms、85% | ChafeとGurevich、AES 117th Convention 2004 |
| 同期したアンサンブル演奏を支えるレイテンシ範囲 | 10〜25 ms | Washburnほか、Frontiers in Psychology 2021(先行研究のレビュー) |
| ソフトウェア音源のポリフォニー、Ryzen 9 9950X、64サンプルと512サンプルのバッファ | 2,140と8,580 | Scan Pro Audio、DAWBench VI |
| プラグインのインスタンス数、Ryzen 9 9950X、64サンプルと512サンプルのバッファ | 482と618 | Scan Pro Audio、DAWBench DSP |
| Windowsオーディオエンジンのレンダリングレイテンシ、Windows 10以降 | 1.3 ms | Microsoft Learn、Low Latency Audio |
| Windows共有モードの既定バッファ | 約10 ms | Microsoft Learn、Low Latency Audio |
| Androidのプロ向けオーディオの往復レイテンシ上限 | 25 ms(アナログでは20 ms) | Android 16 Compatibility Definition Document |
| Bluetooth LEコントローラー接続、操作から音まで | 平均139 ms | McPhersonほか、NIME 2016 |
| 組み込みプラットフォームBela、入力から出力まで | 約0.6 ms | McPhersonほか、NIME 2016 |
| 推奨されるインイヤーモニターのレイテンシ | 5 ms以下 | Shure Insights 2016(メーカーのガイダンス) |
方法論と出典
- MathWorks、Audio Toolboxの「Measure Audio Latency」の例:96 kHzでのバッファサイズ別のループバック往復測定。
- Schmid、Ambros、Bogon、Wimmer、「Measuring the Just Noticeable Difference for Audio Latency」、Audio Mostly 2024:基準レイテンシ別のJND、募集37人、分析34人の参加者。
- Jack、Mehrabi、Stockman、McPherson、「Action-sound Latency and the Perceived Quality of Digital Musical Instruments」、Music Perception 2018。
- McPherson、Jack、Moro、「Action-Sound Latency: Are Our Tools Fast Enough?」、NIME 2016:コントローラー経路の測定と、WesselとWrightの10 ms未満という指針。
- Lester、Boley、「The Effects of Latency on Live Sound Monitoring」、AES Convention Paper 7198(2007):AES E-Libraryのページにアクセスできなかったため、範囲はSchmidほか 2024の要約から読み取った。
- Ozker、Hagoort、「Susceptibility to auditory feedback manipulations and individual variability」、PLoS One 2025。
- Ozker、Giglio、Beyh、Forkel、Hagoort、「Individual differences in speech monitoring」、PNAS 2026。
- Stuart、Kalinowski、Rastatter、Lynch、「Effect of delayed auditory feedback on normal speakers at two speech rates」、JASA 2002。
- Chafe、Gurevich、「Network Time Delay and Ensemble Accuracy: Effects of Latency, Asymmetry」、AES 117th Convention 2004。
- Washburn、Wright、Chafe、Fujioka、「Temporal Coordination in Piano Duet Networked Music Performance」、Frontiers in Psychology 2021。
- Scan Pro Audio、3XS Pro DAW Ryzen 9 9950Xのベンチマーク表と3XS Project DAW Core Ultra 7 270K Plusのベンチマーク表:DAWBench DSPとVIの結果、2026年10月に参照。
- Microsoft Learn、Low Latency Audio(Windowsドライバー)、2025年更新。
- Microsoft Windows Music Devブログ、「Make Great Music with Windows on Arm」、2024年10月とFall 2025 Windows Musician Technology and Arm64 Update、2025年11月。
- Android 16 Compatibility Definition Document、セクション5.6と5.10とAndroid Developers、Audio Latency guide。
- Ableton Help Center、Driver Error Compensation FAQとApple Support、Manage input monitoring latency in Logic Pro for Mac(2026年)。
- Shure Insights、「Digital Wireless Latency Explained」、2016年11月:メーカーのガイダンスであり、引用するたびにその旨を明記した。
- データウォッチ:Android開発者ガイドはプロ向けオーディオのフラグを往復20 msと定義しているが、Android 16のCDDの表ではほとんどの経路で25 ms、アナログのみ20 msとしており、当社は拘束力のある文書としてCDDを採用している。CDDの標準的なハンドヘルド機器の往復の行には、ラベルのない2つの値(250 msと200 ms)が並んでいるため、除外した。Scan Pro Audioの数値は、ドライバーやファームウェアの詳細のない、販売店が製品ページで公開したベンチマークである。MathWorksの例はOSを明示しておらず(ASIOからWindowsと推測される)、1つのインターフェースのみを対象としているため、他のハードウェアでは絶対的なオーバーヘッドは異なる。ピート・ブラウンの「約10 ms」という発言は、Microsoftのブログ投稿の本文ではなく、コメント欄での彼の返信によるものだ。知覚に関するいくつかの数値は、入手できる最新のものだが古い。Stuartほか(2002)、ChafeとGurevich(2004)、LesterとBoley(2007)、McPhersonほか(2016)、Shureのガイダンス(2016)である。Microsoftのインボックス版ASIOおよびUSB Audio Class 2ドライバーは、2025年11月の更新時点でレイテンシの測定値が公開されていなかった。
最終更新日:2026年10月24日。当社はこのまとめを四半期ごとに更新しており、次回の更新は、MicrosoftがWindows Insider Canaryビルドを通じてインボックス版ASIOおよびUSB Audio Class 2ドライバーの公開プレビューをリリースする時期を予定している。