自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
采样率转换
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本文介绍了 Android 中的采样率转换(也称为“重新采样”)。如需查看与采样转化率相关的术语,请参阅术语。
采样率转换是将具有某一采样率的离散样本流更改为具有另一采样率的流的过程。采样率转换器(即重采样器)是执行采样率转换的模块。对于重采样器,原始流称为源信号,而重新采样的流称为设备信号。
在 Android 中有多处需要用到重采样器。例如,MP3 文件可能以 44.1kHz 的采样率编码,但需要在内部支持 48kHz 音频的 Android 设备上进行播放。在这种情况下,会使用重采样器将 MP3 输出音频从 44.1kHz 源采样率升采样到 Android 设备中使用的 48kHz 设备采样率。
重采样器的特性可以使用指标来表示,包括:
- 信号整体幅度的保存程度
- 信号频率带宽的保存程度(受设备采样率的限制)
- 通过重采样器的整体延迟时间
- 有关频率的一致相位和群组延迟
- 计算复杂度(以 CPU 周期或功耗表示)
- 允许的源采样率和设备采样率的比率
- 动态更改采样率比率的能力
- 支持的数字音频采样格式
理想的重采样器具有如下特点:精确保留源信号的幅度和频率带宽(受接收器采样率的限制)、具有最短且一致的延迟时间、计算复杂度极低、允许任意动态转换比率,并且支持所有常见的数字音频采样格式。实际上,理想的重采样器并不存在,因为实际的重采样器会在这些特性上进行折衷。例如,理想质量的目标与短延迟时间和低复杂度相冲突。
Android 包括各种音频重采样器,因此可以根据应用用例和负载进行适当折衷。重采样器实现部分介绍了可用的重采样器。
重采样器实现
可用的重新采样器实现会频繁变化,并且可由原始设备制造商 (OEM) 自定义。默认重新采样器包括(按照信号失真降序和计算复杂度升序的顺序):
- 线性
- 立方
- 具有原始系数的 sinc
- 具有修订系数的 sinc
一般来说,sinc 重采样器更适合用来播放品质较高的音乐,而其他重采样器也应保留下来,以便在质量要求不那么高的情况(例如“按键声”或类似情况)下使用。
所选择的特定重采样器实现取决于用例、负载以及系统属性 af.resampler.quality
的值。如需了解详情,请参阅 AudioFlinger 中的音频重采样器源代码。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):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"]],["最后更新时间 (UTC):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/)."]]