自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
取樣率轉換
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本文將說明 Android 中的取樣率轉換作業,也稱為「重新取樣」。如要瞭解與取樣率轉換相關的術語,請參閱術語。
取樣率轉換是指將離散取樣串流從一個取樣率變更為另一個取樣率的串流。取樣率轉換器 (或稱重取樣器) 是實作取樣率轉換的模組。就重新取樣器而言,原始串流稱為來源訊號,而重新取樣的串流則稱為接收訊號。
重取樣器可用於 Android 的多個位置。舉例來說,MP3 檔案可能會以 44.1 kHz 取樣率編碼,但需要在內部支援 48 kHz 音訊的 Android 裝置上播放。在這種情況下,系統會使用重新取樣器,將 MP3 輸出音訊從 44.1 kHz 來源取樣率升至 Android 裝置中使用的 48 kHz 接收器取樣率。
您可以使用指標表達重新取樣器的特性,包括:
- 保留訊號整體振幅的程度
- 信號頻率頻寬的保留程度,取決於接收器取樣率的限制
- 透過重新取樣器的整體延遲時間
- 相對於頻率的一致相位和群組延遲
- 運算複雜度,以 CPU 週期或耗電量表示
- 來源和接收端取樣率的允許比率
- 能夠動態變更取樣率比率
- 系統支援哪些數位音訊取樣格式
理想的重新取樣器會確實保留來源訊號的振幅和頻率頻寬 (取決於接收器取樣率的限制),並提供最小且一致的延遲時間、最小運算複雜度、允許任意和動態轉換比率,以及支援所有常見的數位音訊取樣格式。實際上,理想的重新取樣器並不存在,因為實際的重新取樣器是這些特性的折衷。舉例來說,理想品質的目標與短延遲和低複雜度相衝突。
Android 內建多種音訊重新取樣器,可視應用程式用途和負載量做出適當的折衷。可用的重新取樣器說明請參閱「重新取樣器實作」。
重取樣器實作
可用的重新取樣器實作方式經常變更,且可能由原始設備製造商 (OEM) 自訂。預設的重新取樣器依信號失真程度遞減,以及運算複雜度遞增的順序排列如下:
- 線性
- 立方
- 使用原始係數的 sinc
- 使用經過修訂的係數的 sinc
一般來說,sinc 重新取樣器更適合用於播放較高品質的音樂,而其他重新取樣器則應保留給品質較不重要的情況 (例如「按鍵點擊」或類似情況)。
所選取的特定重新取樣器實作方式取決於用途、負載和系統屬性 af.resampler.quality
的值。詳情請參閱 AudioFlinger 中的音訊重新取樣器原始碼。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-03-26 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],null,["# Sample rate conversion\n\nThis article describes sample rate conversion, also known as *resampling* , within Android.\nFor terminology related to sample rate conversion, see\n[Terminology](/docs/core/audio/terminology#srcTerms).\n\n\nSample rate conversion is the process of changing a stream of discrete samples\nfrom one sample rate to another stream at a different sample rate.\nA sample rate converter, or resampler, is a module that implements sample rate\nconversion. With respect to the resampler, the original stream is called the\nsource signal, and the resampled stream is called the sink signal.\n\n\nResamplers are used in several places in Android. For example, an MP3 file may\nbe encoded at 44.1 kHz sample rate but needs to be played back on an Android\ndevice supporting 48 kHz audio internally. In that case, a resampler would be\nused to upsample the MP3 output audio from 44.1 kHz source sample rate to a\n48 kHz sink sample rate used within the Android device.\n\n\nThe characteristics of a resampler can be expressed using metrics, including:\n\n- degree of preservation of the overall amplitude of the signal\n- degree of preservation of the frequency bandwidth of the signal, subject to limitations of the sink sample rate\n- overall latency through the resampler\n- consistent phase and group delay with respect to frequency\n- computational complexity, expressed in CPU cycles or power draw\n- permitted ratios of source and sink sample rates\n- ability to dynamically change sample rate ratios\n- which digital audio sample formats are supported\n\n\nThe ideal resampler would exactly preserve the source signal's amplitude\nand frequency bandwidth (subject to limitations of the sink\nsample rate), have minimal and consistent delay, have minimal\ncomputational complexity, permit arbitrary and dynamic conversion ratios,\nand support all common digital audio sample formats. In practice, ideal\nresamplers do not exist as actual resamplers are a compromise among these\ncharacteristics. For example, goals of ideal quality conflict with short delay\nand low complexity.\n\n\nAndroid includes a variety of audio resamplers, so that appropriate\ncompromises can be made depending on the application use case and load. The\navailable resamplers are explained in [Resampler implementation.](#srcResamplers)\n\nResampler implementations\n-------------------------\n\n\nAvailable resampler implementations change frequently,\nand may be customized by OEMs.\nThe default resamplers, in descending order of signal distortion and ascending order of\ncomputational complexity, include:\n\n- linear\n- cubic\n- sinc with original coefficients\n- sinc with revised coefficients\n\n\nIn general, the sinc resamplers are more appropriate for higher-quality\nmusic playback, and the other resamplers should be reserved for cases\nwhere quality is less important (an example might be \"key clicks\" or similar).\n\n\nThe specific resampler implementation selected depends on\nthe use case, load, and the value of system property\n`af.resampler.quality`. For details,\nconsult the audio resampler source code in\n[AudioFlinger](https://android.googlesource.com/platform/frameworks/av/+/39ec5a7accf61d89a41908999bc789d5c8d0e3d3/services/audioflinger/)."]]