2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
オーディオ レイテンシの原因
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このページでは、出力レイテンシに焦点を当てて説明していますが、入力レイテンシについても同じことが当てはまります。
アナログ回路による影響が少ないと仮定した場合、表層レベルでのオーディオ レイテンシの主な原因は次のとおりです。
- アプリ
- パイプライン内のバッファの総数
- 各バッファのサイズ（フレーム数）
- アプリ プロセッサの後に発生する追加のレイテンシ（DSP からなど）
上記のリストを参照した場合でも、原因の特定が困難なことがあります。
その理由は、バッファ数とバッファサイズによる「影響」が「原因」として認識されるよりも大きいためです。通常は、任意のバッファ スキームを用いてテストを行いますが、テスト中に発生したオーディオ アンダーランまたはオーバーランはクリック音やポップ音として聞こえます。これを補正するため、システムの設計者はバッファサイズまたはバッファ数を増やします。その結果、アンダーランまたはオーバーランは発生しなくなりますが、レイテンシが増加するという副次的な作用がもたらされます。バッファサイズの詳細については、オーディオ レイテンシ: バッファサイズ（英語）を参照してください。
この場合、アンダーランとオーバーランの原因を特定し、修正することがより効果的です。これにより、可聴アーティファクトがなくなり、バッファ数を減らしてレイテンシを削減できます。
これまでの経験から、最も一般的なアンダーランとオーバーランの原因は次のとおりです。
- Linux の CFS（Completely Fair Scheduler）
- SCHED_FIFO スケジューリングによる高優先度スレッド
- 優先順位の逆転
- 長時間のスケジューリング レイテンシ
- 長時間実行の割り込みハンドラ
- 長時間の割り込み禁止時間
- 電力管理
- セキュリティ カーネル
Linux の CFS スケジューリングと SCHED_FIFO スケジューリング
Linux の CFS は、共通の CPU リソースを共有する競合したワークロードが均等になるように設計されています。この均等性は、スレッドごとに nice パラメータとして表されます。
nice 値の範囲は、-19（最小の nice 値、または最も多くの CPU 時間を割り当て）から 20（最適な CPU 時間を割り当て）までとなります。通常、任意の nice 値を持つすべてのスレッドはほぼ同等の CPU 時間を受け取り、低い nice 値を持つスレッドはより多くの CPU 時間を受け取るようになっています。ただし、CFS は比較的長期間に及ぶモニタリングを通して「均等性」を提供するため、短期的なモニタリングの場合、CFS は想定されない方法で CPU リソースを割り当てます。たとえば、数値が低い nice を持つスレッドから高い数値の nice を持つスレッドに CPU が割り当てられる場合もあります。このような場合、オーディオのアンダーランやオーバーランが発生する可能性があります。
確実な解決方法としては、高性能オーディオ スレッドの CFS を回避することがあげられます。Android 4.1 以降、このようなスレッドでは、CFS によって用いられる SCHED_NORMAL（SCHED_OTHER とも呼ばれます）スケジューリング ポリシーではなく、SCHED_FIFO スケジューリング ポリシーが使用されるようになりました。
SCHED_FIFO の優先度
高性能オーディオ スレッドでは現在 SCHED_FIFO が使用されていますが、依然として優先度の高い他の SCHED_FIFO スレッドの影響を受けやすい状態です。これらのスレッドは通常、カーネル ワーカー スレッドですが、ポリシー SCHED_FIFO を使用したオーディオ以外のユーザー スレッドが一部存在する場合があります。利用可能な SCHED_FIFO 優先度の範囲は 1～99 です。オーディオ スレッドは優先度 2 または 3 で実行されます。これにより、優先度 1 が優先度の低いスレッドで、また、優先度 4～99 は優先度の高いスレッドで使用可能になります。可能な限り優先度は 1 を使用し、制限された時間内に完了することが保証されること、オーディオ スレッドの周期よりも短い周期で実行されること、オーディオ スレッドのスケジューリングに干渉しないことがわかっているスレッドには、優先度 4～99 を予約することをおすすめします。
レートモノトニック スケジューリング
固定優先度の割り当てに関する理論については、Wikipedia の記事レートモノトニックス スケジューリング（RMS）を参照してください。重要なのは、固定優先度は知覚される「重要度」ではなく、より高い優先度を持つ周期に基づいて短い周期のスレッドへ厳密に割り当てられるということです。非周期的スレッドは、実行の最大頻度と各実行の最大計算を使用して、周期的スレッドとしてモデル化することができます。周期的スレッドとして非周期的スレッドをモデル化できない場合（たとえば、実行ごとに無制限の頻度または無制限の計算で実行できる場合）は、真の周期的スレッドのスケジューリングと互換性を持たないため、固定優先度を割り当てないようにしてください。
優先順位の逆転
優先順位の逆転は、リアルタイム システムで昔から存在する障害モードです。この障害では、優先順位の低いタスクがミューテックスのような（共有状態がロックされた）リソースを解放するまで、優先順位の高いタスクが無期限にブロックされてしまいます。これを緩和するには、優先順位の逆転を回避するを参照してください。
スケジューリング レイテンシ
スケジューリング レイテンシとは、スレッドが実行可能な状態になってから、その結果としてコンテキストの切り替えが完了してスレッドが実際に CPU 上で実行されるまでの時間です。レイテンシが短いほど良好で、2 ミリ秒を超える場合はオーディオで問題が発生します。CPU の起動またはシャットダウン、セキュリティ カーネルと通常のカーネルの切り替え、フルパワー モードから低電力モードへの切り替え、CPU クロック周波数と電圧の調整といったモードの移行中に長時間のスケジューリング レイテンシが発生する可能性が最も高くなります。
割り込み
多くの設計において、CPU 0 はすべての外部割り込みを処理します。そのため、長時間実行の割り込みハンドラによって他の割り込み、特にオーディオ Direct Memory Access（DMA）完了割り込みが遅延する可能性があります。迅速に終了するためには、割り込みハンドラを設計して長時間の作業をスレッド（可能であれば優先度 1 の CFS スレッドまたは SCHED_FIFO スレッド）に委ねるようにします。
同様に、CPU 0 での割り込みを長時間無効にすることは、オーディオ割り込みの処理を遅延させることと同じ結果をもたらします。カーネルのスピンロックを待機している間は、長時間の割り込み無効化時間が発生します。こうしたスピンロックが制限されていることを確認します。
電力、パフォーマンス、温度の管理
電力管理とは、パフォーマンスの最適化を行いながら消費電力を監視および削減する取り組みという広い意味合いを持つ用語です。温度の管理とコンピュータ冷却は似ていますが、どちらも温度の測定と制御を行い、過剰な熱による損傷を防ぐためのものです。Linux カーネルでは、CPU ガバナーが低レベルのポリシーを処理し、ユーザーモードが高レベルのポリシーを構成します。使用される手法は次のとおりです。
- 動的電圧スケーリング
- 動的周波数スケーリング
- 動的コア有効化
- クラスタ切り替え
- パワー ゲーティング
- hotplug（ホットスワップ）
- 各種のスリープモード（中断、停止、アイドル、サスペンドなど）
- プロセスの移行
- プロセッサ アフィニティ
一部の管理操作により、「作業停止」またはアプリケーション プロセッサによって実行される有用な作業がない時間が発生する可能性があります。作業停止が音声に干渉する可能性があるため、このような管理操作については、音声がアクティブである間の許容可能な最悪のケースの作業停止に合わせて設計する必要があります。しかし、熱暴走の危険性がある場合は、音声よりも恒久的な損傷を避けることが重要です。
セキュリティ カーネル
デジタル著作権管理（DRM）のセキュリティ カーネルは、メインのオペレーティング システム カーネルおよびアプリケーション コードに使用されるものと同一のアプリケーション プロセッサ コアで実行されます。コア上でセキュリティ カーネル操作がアクティブになると、通常はそのコアで実行される通常の作業が事実上停止します。これには特に音声作業が含まれます。その性質上、セキュリティ カーネルの内部動作は上位層から検知不可能であるため、セキュリティ カーネルに起因するパフォーマンス異常は特に有害です。たとえば、セキュリティ カーネルによる操作は、通常、コンテキスト切り替えのトレースには表示されません。これは「暗黒の時間」（経過したがモニタリングできない時間）と呼ばれます。セキュリティ カーネルは、音声がアクティブである間の許容可能な最悪のケースの作業停止に合わせて設計する必要があります。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-26 UTC。"],[],[],null,["# Contributors to audio latency\n\nThis page focuses on the contributors to output latency,\nbut a similar discussion applies to input latency.\n\n\nAssuming the analog circuitry does not contribute significantly, then the major\nsurface-level contributors to audio latency are the following:\n\n- Application\n- Total number of buffers in pipeline\n- Size of each buffer, in frames\n- Additional latency after the app processor, such as from a DSP\n\n\nAs accurate as the above list of contributors may be, it is also misleading.\nThe reason is that buffer count and buffer size are more of an\n*effect* than a *cause* . What usually happens is that\na given buffer scheme is implemented and tested, but during testing, an audio\nunderrun or overrun is heard as a \"click\" or \"pop.\" To compensate, the\nsystem designer then increases buffer sizes or buffer counts.\nThis has the desired result of eliminating the underruns or overruns, but it also\nhas the undesired side effect of increasing latency.\nFor more information about buffer sizes, see the video\n[Audio latency: buffer sizes](https://youtu.be/PnDK17zP9BI).\n\n\nA better approach is to understand the causes of the\nunderruns and overruns, and then correct those. This eliminates the\naudible artifacts and may permit even smaller or fewer buffers\nand thus reduce latency.\n\n\nIn our experience, the most common causes of underruns and overruns include:\n\n- Linux CFS (Completely Fair Scheduler)\n- high-priority threads with SCHED_FIFO scheduling\n- priority inversion\n- long scheduling latency\n- long-running interrupt handlers\n- long interrupt disable time\n- power management\n- security kernels\n\n### Linux CFS and SCHED_FIFO scheduling\n\n\nThe Linux CFS is designed to be fair to competing workloads sharing a common CPU\nresource. This fairness is represented by a per-thread *nice* parameter.\nThe nice value ranges from -19 (least nice, or most CPU time allocated)\nto 20 (nicest, or least CPU time allocated). In general, all threads with a given\nnice value receive approximately equal CPU time and threads with a\nnumerically lower nice value should expect to\nreceive more CPU time. However, CFS is \"fair\" only over relatively long\nperiods of observation. Over short-term observation windows,\nCFS may allocate the CPU resource in unexpected ways. For example, it\nmay take the CPU away from a thread with numerically low niceness\nonto a thread with a numerically high niceness. In the case of audio,\nthis can result in an underrun or overrun.\n\n\nThe obvious solution is to avoid CFS for high-performance audio\nthreads. Beginning with Android 4.1, such threads now use the\n`SCHED_FIFO` scheduling policy rather than the `SCHED_NORMAL` (also called\n`SCHED_OTHER`) scheduling policy implemented by CFS.\n\n### SCHED_FIFO priorities\n\n\nThough the high-performance audio threads now use `SCHED_FIFO`, they\nare still susceptible to other higher priority `SCHED_FIFO` threads.\nThese are typically kernel worker threads, but there may also be a few\nnon-audio user threads with policy `SCHED_FIFO`. The available `SCHED_FIFO`\npriorities range from 1 to 99. The audio threads run at priority\n2 or 3. This leaves priority 1 available for lower priority threads,\nand priorities 4 to 99 for higher priority threads. We recommend\nyou use priority 1 whenever possible, and reserve priorities 4 to 99 for\nthose threads that are guaranteed to complete within a bounded amount\nof time, execute with a period shorter than the period of audio threads,\nand are known to not interfere with scheduling of audio threads.\n\n### Rate-monotonic scheduling\n\n\nFor more information on the theory of assignment of fixed priorities,\nsee the Wikipedia article\n[Rate-monotonic scheduling](http://en.wikipedia.org/wiki/Rate-monotonic_scheduling) (RMS).\nA key point is that fixed priorities should be allocated strictly based on period,\nwith higher priorities assigned to threads of shorter periods, not based on perceived \"importance.\"\nNon-periodic threads may be modeled as periodic threads, using the maximum frequency of execution\nand maximum computation per execution. If a non-periodic thread cannot be modeled as\na periodic thread (for example it could execute with unbounded frequency or unbounded computation\nper execution), then it should not be assigned a fixed priority as that would be incompatible\nwith the scheduling of true periodic threads.\n\n### Priority inversion\n\n\n[Priority inversion](http://en.wikipedia.org/wiki/Priority_inversion)\nis a classic failure mode of real-time systems,\nwhere a higher-priority task is blocked for an unbounded time waiting\nfor a lower-priority task to release a resource such as (shared\nstate protected by) a\n[mutex](http://en.wikipedia.org/wiki/Mutual_exclusion).\nSee the article \"[Avoiding priority inversion](/docs/core/audio/avoiding_pi)\" for techniques to\nmitigate it.\n\n### Scheduling latency\n\n\nScheduling latency is the time between when a thread becomes\nready to run and when the resulting context switch completes so that the\nthread actually runs on a CPU. The shorter the latency the better, and\nanything over two milliseconds causes problems for audio. Long scheduling\nlatency is most likely to occur during mode transitions, such as\nbringing up or shutting down a CPU, switching between a security kernel\nand the normal kernel, switching from full power to low-power mode,\nor adjusting the CPU clock frequency and voltage.\n\n### Interrupts\n\n\nIn many designs, CPU 0 services all external interrupts. So a\nlong-running interrupt handler may delay other interrupts, in particular\naudio direct memory access (DMA) completion interrupts. Design interrupt handlers\nto finish quickly and defer lengthy work to a thread (preferably\na CFS thread or `SCHED_FIFO` thread of priority 1).\n\n\nEquivalently, disabling interrupts on CPU 0 for a long period\nhas the same result of delaying the servicing of audio interrupts.\nLong interrupt disable times typically happen while waiting for a kernel\n*spin lock*. Review these spin locks to ensure they are bounded.\n\n### Power, performance, and thermal management\n\n\n[Power management](http://en.wikipedia.org/wiki/Power_management)\nis a broad term that encompasses efforts to monitor\nand reduce power consumption while optimizing performance.\n[Thermal management](http://en.wikipedia.org/wiki/Thermal_management_of_electronic_devices_and_systems)\nand [computer cooling](http://en.wikipedia.org/wiki/Computer_cooling)\nare similar but seek to measure and control heat to avoid damage due to excess heat.\nIn the Linux kernel, the CPU\n[governor](http://en.wikipedia.org/wiki/Governor_%28device%29)\nis responsible for low-level policy, while user mode configures high-level policy.\nTechniques used include:\n\n- dynamic voltage scaling\n- dynamic frequency scaling\n- dynamic core enabling\n- cluster switching\n- power gating\n- hotplug (hotswap)\n- various sleep modes (halt, stop, idle, suspend, etc.)\n- process migration\n- [processor affinity](http://en.wikipedia.org/wiki/Processor_affinity)\n\n\nSome management operations can result in \"work stoppages\" or\ntimes during which there is no useful work performed by the application processor.\nThese work stoppages can interfere with audio, so such management should be designed\nfor an acceptable worst-case work stoppage while audio is active.\nOf course, when thermal runaway is imminent, avoiding permanent damage\nis more important than audio!\n\n### Security kernels\n\n\nA [security kernel](http://en.wikipedia.org/wiki/Security_kernel) for\n[Digital rights management](http://en.wikipedia.org/wiki/Digital_rights_management)\n(DRM) may run on the same application processor core(s) as those used\nfor the main operating system kernel and application code. Any time\nduring which a security kernel operation is active on a core is effectively a\nstoppage of ordinary work that would normally run on that core.\nIn particular, this may include audio work. By its nature, the internal\nbehavior of a security kernel is inscrutable from higher-level layers, and thus\nany performance anomalies caused by a security kernel are especially\npernicious. For example, security kernel operations do not typically appear in\ncontext switch traces. We call this \"dark time\" --- time that elapses\nyet cannot be observed. Security kernels should be designed for an\nacceptable worst-case work stoppage while audio is active."]]
