自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
減少延遲時間的設計
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
供應商可以實作兩項重要功能,減少音訊延遲:
- AudioFlinger 中的 FAST Mixer:Android 4.1 推出這項功能,支援使用 Java AudioTrack 和 AAudio 的應用程式。FAST Mixer 涉及的公開用戶端 API 或 HAL API 變更最少。
- AAudio MMAP:Android 8.1 推出的這項功能可讓原生應用程式透過 AAudio 達到更低的延遲。詳情請參閱 AAudio 和 MMAP。
本頁面說明初始音訊延遲設計,這項設計隨著時間不斷演進。裝置 OEM 和 SoC 供應商必須深入瞭解這項設計,才能確保在特定裝置和晶片組上正確實作。本頁面不適用於應用程式開發人員。
建立測試群組
用戶端可以選擇在 AudioTrack C++ 建構函式的 audio_output_flags_t
參數中設定位元 AUDIO_OUTPUT_FLAG_FAST
,或使用 AudioTrack::set()
。目前只有下列用戶端會這麼做:
AudioTrack C++ 實作會檢查AUDIO_OUTPUT_FLAG_FAST
要求,並視需要選擇在用戶端層級拒絕要求。如果決定要轉送要求,會使用 IAudioTrack
工廠方法 IAudioFlinger::createTrack()
的 track_flags_t
參數中的 TRACK_FAST
位元。
AudioFlinger 音訊伺服器會檢查 TRACK_FAST
要求,並視需要拒絕伺服器層級的要求。並透過共用記憶體控制區塊的位元 CBLK_FAST
,告知用戶端要求是否已獲准。
影響決定的因素包括:
- 這個輸出內容有快速混音器執行緒 (請參閱下文)
- 追蹤記錄取樣率
- 是否有用戶端執行緒可執行這個軌道的處理常式
- 追蹤緩衝區大小
- 可用的快速通道名額 (請見下文)
如果客戶的要求獲得核准,即為快速通道。否則稱為「一般軌道」。
混音器執行緒
AudioFlinger 建立一般混音器執行緒時,會決定是否同時建立快速混音器執行緒。一般混音器和快速混音器都不會與特定音軌建立關聯,而是與一組音軌建立關聯。一律會有正常的混音器執行緒。如果存在快速混音器執行緒,則會從屬於一般混音器執行緒,並受其控制。
快速混音器
功能
快速混音器執行緒提供下列功能:
- 混合一般混音器的子混音和最多七個用戶端快速音軌
- 每條音軌的衰減
省略的功能:
句號
快速混音器會定期執行,建議週期為 2 到 3 毫秒,如果需要排程穩定性,則可稍微提高至 5 毫秒。選擇這個數字是為了考量完整的緩衝區管道,讓總延遲時間達到 10 毫秒左右。雖然可以選擇較小的值,但可能會導致耗電量增加,且視 CPU 排程可預測性而定,發生故障的機率也會提高。值可以更大 (最多 20 毫秒),但會導致總延遲時間變長,因此應避免使用。
時段設定
快速混音器會以較高的SCHED_FIFO
優先順序執行,這類工作需要極少的 CPU 時間,但必須經常執行,且排程抖動要低。抖動
表示週期時間的變化,也就是實際週期時間與預期週期時間之間的差異。
如果太晚執行,可能會因緩衝區不足而發生故障。如果太早執行,系統會從快速通道提取資料,但該通道尚未提供資料,因此會發生故障。
會使影片被封鎖
理想情況下,快速混音器執行緒絕不會遭到封鎖,HAL
write()
除外。快速混合器內的其他封鎖情況則視為錯誤。尤其是避免使用互斥鎖。而是使用非阻塞演算法 (也稱為無鎖演算法)。如要進一步瞭解這個主題,請參閱「避免優先權反轉」。
與其他元件的關係
快速混音師與客戶的直接互動較少,具體來說,它不會看到繫結層級的作業,但會存取用戶端的共用記憶體控制區塊。
快速混音器會透過狀態佇列接收一般混音器的指令。
除了擷取音軌資料,與用戶互動的方式與一般混音器相同。
快速混音器的主要接收器是音訊 HAL。
一般混音器
功能
所有功能皆已啟用:
- 最多 32 條音軌
- 每條音軌的衰減
- 依音軌轉換取樣率
- 處理特效
句號
計算出的時間長度為快速混音器週期的第一個整數倍數,且 >= 20 毫秒。
時段設定
一般混音器會以較高的 SCHED_OTHER
優先順序執行。
會使影片被封鎖
一般混音器可以封鎖,而且通常會在各種互斥鎖,以及封鎖管道寫入子混音時封鎖。
與其他元件的關係
一般混音器會與外部世界大量互動,包括繫結器執行緒、音訊政策管理員、快速混音器執行緒和用戶端軌。
一般混音器的接收器是快速混音器軌道 0 的封鎖管道。
旗幟
AUDIO_OUTPUT_FLAG_FAST
位元是提示。我們無法保證一定會滿足要求。
AUDIO_OUTPUT_FLAG_FAST
是指用戶端層級的概念。不會顯示在伺服器中。
TRACK_FAST
是用戶端對伺服器的概念。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-08-10 (世界標準時間)。
[[["容易理解","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-08-10 (世界標準時間)。"],[],[],null,["# Design for reduced latency\n\nVendors can implement two key features to reduce audio latency:\n\n- **FAST Mixer in AudioFlinger:** Introduced in Android 4.1, this feature supports apps using Java AudioTrack and AAudio. The FAST Mixer involves minimal public client API or HAL API changes.\n- **AAudio MMAP:** Introduced in Android 8.1, this feature enables native apps to achieve even lower latency through AAudio. See [AAudio and MMAP](/docs/core/audio/aaudio) for more information.\n\n\nThis page describes the initial audio latency design, which has continued to evolve over time. A\nstrong understanding of this design is crucial for device OEMs and SoC vendors to ensure correct\nimplementation on their specific devices and chipsets. This page isn't intended for app\ndevelopers.\n\nTrack creation\n--------------\n\n\nThe client can optionally set bit `AUDIO_OUTPUT_FLAG_FAST` in the\n`audio_output_flags_t` parameter of AudioTrack C++ constructor or\n`AudioTrack::set()`. Currently the only clients that do so are:\n\n- Android native audio based on [OpenSL\n ES](https://developer.android.com/ndk/guides/audio/opensl/index.html) or [AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)\n- [`android.media.SoundPool`](http://developer.android.com/reference/android/media/SoundPool.html)\n- [`android.media.ToneGenerator`](http://developer.android.com/reference/android/media/ToneGenerator.html)\n\n\nThe AudioTrack C++ implementation reviews the `AUDIO_OUTPUT_FLAG_FAST`\nrequest and may optionally deny the request at client level. If it\ndecides to pass the request on, it does so using `TRACK_FAST` bit of\nthe `track_flags_t` parameter of the `IAudioTrack` factory method\n`IAudioFlinger::createTrack()`.\n\n\nThe AudioFlinger audio server reviews the `TRACK_FAST` request and may\noptionally deny the request at server level. It informs the client\nwhether or not the request was accepted, through bit `CBLK_FAST` of the\nshared memory control block.\n\n\nThe factors that impact the decision include:\n\n- Presence of a fast mixer thread for this output (see below)\n- Track sample rate\n- Presence of a client thread to execute callback handlers for this track\n- Track buffer size\n- Available fast track slots (see below)\n\n\nIf the client's request was accepted, it's called a *fast track* . Otherwise it's called a\n*normal track*.\n\nMixer threads\n-------------\n\n\nAt the time AudioFlinger creates a normal mixer thread, it decides\nwhether or not to also create a fast mixer thread. Both the normal\nmixer and fast mixer are not associated with a particular track,\nbut rather with a set of tracks. There is always a normal mixer\nthread. The fast mixer thread, if it exists, is subservient to the\nnormal mixer thread and acts under its control.\n\n### Fast mixer\n\n#### Features\n\n\nThe fast mixer thread provides these features:\n\n- Mixing of the normal mixer's sub-mix and up to seven client fast tracks\n- Per track attenuation\n\n\nOmitted features:\n\n- Per track sample rate conversion\n- Per track effects\n- Per mix effects\n\n#### Period\n\n\nThe fast mixer runs periodically, with a recommended period of two\nto three milliseconds, or a slightly higher period of 5 ms if needed for scheduling\nstability.\nThis number was chosen so that, accounting for the complete\nbuffer pipeline, the total latency is on the order of 10 ms. Smaller\nvalues are possible but may result in increased power consumption\nand chance of glitches depending on CPU scheduling predictability.\nLarger values are possible, up to 20 ms, but result in degraded\ntotal latency and so should be avoided.\n\n#### Scheduling\n\n\nThe fast mixer runs at elevated `SCHED_FIFO` priority. It needs very\nlittle CPU time, but must run often and with low scheduling jitter.\n[Jitter](http://en.wikipedia.org/wiki/Jitter)\nexpresses the variation in cycle time: it's the difference between the\nactual cycle time versus the expected cycle time.\nRunning too late results in glitches due to underrun. Running\ntoo early results in glitches due to pulling from a fast track\nbefore the track has provided data.\n\n#### Blocking\n\n\nIdeally the fast mixer thread never blocks, other than at HAL\n`write()`. Other occurrences of blocking within the fast mixer are\nconsidered bugs. In particular, mutexes are avoided.\nInstead, [non-blocking algorithms](http://en.wikipedia.org/wiki/Non-blocking_algorithm)\n(also known as lock-free algorithms) are used.\nSee [Avoid priority inversion](/docs/core/audio/avoiding_pi) for more on this topic.\n\n#### Relationship to other components\n\n\nThe fast mixer has little direct interaction with clients. In\nparticular, it does not see binder-level operations, but it does\naccess the client's shared memory control block.\n\n\nThe fast mixer receives commands from the normal mixer through a state queue.\n\n\nOther than pulling track data, interaction with clients is through the normal mixer.\n\n\nThe fast mixer's primary sink is the audio HAL.\n\n### Normal mixer\n\n#### Features\n\n\nAll features are enabled:\n\n- Up to 32 tracks\n- Per track attenuation\n- Per track sample rate conversion\n- Effects processing\n\n#### Period\n\n\nThe period is computed to be the first integral multiple of the\nfast mixer period that is \\\u003e= 20 ms.\n\n#### Scheduling\n\n\nThe normal mixer runs at elevated `SCHED_OTHER` priority.\n\n#### Blocking\n\n\nThe normal mixer is permitted to block, and often does so at various\nmutexes as well as at a blocking pipe to write its sub-mix.\n\n#### Relationship to other components\n\n\nThe normal mixer interacts extensively with the outside world,\nincluding binder threads, audio policy manager, fast mixer thread,\nand client tracks.\n\n\nThe normal mixer's sink is a blocking pipe to the fast mixer's track 0.\n\nFlags\n-----\n\n\n`AUDIO_OUTPUT_FLAG_FAST` bit is a hint. There's no guarantee the\nrequest will be fulfilled.\n\n\n`AUDIO_OUTPUT_FLAG_FAST` is a client-level concept. It does not appear\nin server.\n\n\n`TRACK_FAST` is a client -\\\u003e server concept."]]