在iOS上做带后台音乐播放的语音通话或直播应用，最常见的翻车点就是音频会话配置不当导致要么音乐中断、要么回声刺耳。语音突显模式（Voice Isolation）和后台音频混播看起来是矛盾的：前者要求系统对麦克风信号做深度处理，后者又希望其他音频源持续输出。实际上通过合理的AVAudioSession选型，再配合语音处理IO内部的波束成形与回声消除链路，可以实现两者兼顾。
音频会话配置的冲突点与选型
很多开发者习惯用AVAudioSessionCategoryPlayAndRecord来做双向音频应用，但往往忽略mode和options的组合。如果只设置category为playAndRecord而不指定mode为voiceChat，系统不会自动启用语音突显级别的降噪与回声消除。反过来，如果设置了voiceChat却忘记加mixWithOthers，一旦应用进入后台，正在播放的背景音乐或系统提示音就会被强制打断。正确做法是先明确应用内的音频角色：语音通话是主线，背景音乐或音效是辅助，两者必须同时发声。
在AVAudioSession中，category决定音频的基本行为，mode决定系统应用的语音处理策略。使用AVAudioSession.Mode.voiceChat时，系统会优先保证人声可懂度，自动调节麦克风增益并启用回声消除。此时如果不加mixWithOthers，系统会把当前会话设置为独占，其他应用的音频会被压低或完全暂停。加上mixWithOthers后，其他音频可以混合进来，但代价是回声消除的参考信号变得复杂：系统无法完整获取外部应用的音频数据，AEC滤波器的收敛效果会下降。因此，如果后台播放的是应用自己生成的音乐，建议不要把音乐完全交给其他会话处理，而是通过AVAudioEngine将音乐注入语音处理IO的输出总线，让AEC能够拿到准确的参考信号。
下面是一段基础的会话配置代码，展示了playAndRecord、voiceChat和mixWithOthers的组合。需要特别注意的是，如果允许蓝牙设备接入，还要加上allowBluetooth选项，否则蓝牙耳机场景下路由会异常。
import AVFoundation
func configureAudioSessionForPlayAndRecord() throws {
let session = AVAudioSession.sharedInstance()
try session.setCategory(
.playAndRecord,
mode: .voiceChat,
options: [.mixWithOthers, .allowBluetooth]
)
try session.setPreferredSampleRate(48000)
try session.setPreferredIOBufferDuration(0.01)
try session.setActive(true, options: [])
}
这段配置的核心在于mode为voiceChat，它会让系统底层优先启用语音处理单元。很多团队在这个基础上直接调用AVAudioEngine的inputNode，但如果没有把应用内播放的音乐信号接入同一个音频图，AEC的参考信号就只剩麦克风输入端的扬声器串扰估计值。一旦扬声器音量较大，估计误差会导致回声残留或双讲抑制过度。因此，后续的联合优化必须围绕参考信号对齐展开。
波束成形与回声消除的联合优化链路
波束成形的目标是从多麦克风阵列中提取目标方向的语音，抑制来自其他方向的环境噪声和扬声器扩散声。在后台音乐混播场景下，音乐声往往是从设备扬声器以近似全向方式辐射出去的，波束成形无法完全剔除这种近场强干扰。单纯依靠波束成形会让音乐声的某些频段仍然漏入麦克风信号，听感上就像语音里混着背景伴奏。此时需要回声消除在波束成形之后做二次处理，利用参考信号把音乐成分从波束输出中减掉。
联合优化的顺序很关键。如果把波束成形放在回声消除之后，AEC需要对多路麦克风分别做滤波，计算量大幅上升，而且各路信号之间的相位关系可能被独立调整，反而破坏波束成形的相干性。更合理的做法是先对多路麦克风信号做延迟对齐和加权求和，得到一路波束输出，再把这一路输出送入AEC。这样AEC只需要处理单路信号，滤波器阶数可以保持较低，收敛速度也更快。参考信号必须取自播放音乐流的最终混合前数据，不能取扬声器物理端口之后的信号，否则延迟估计会偏差一个缓冲区以上。
下面这段伪代码展示了一个典型的联合优化循环，其中延迟对齐模块负责估计扬声器到麦克风的时延，波束成形模块做空间滤波，AEC模块用自适应滤波器估计回声路径。
// 联合优化循环：延迟对齐 -> 波束成形 -> 回声消除
for each frame:
ref_delayed = delay_align(speaker_ref, estimated_delay)
beam_out = beamform(mic_array_input, target_angle)
err = beam_out - adaptive_filter(ref_delayed)
update_filter_coefficients(adaptive_filter, ref_delayed, err, step_size)
if double_talk_detected:
freeze_filter_update()
output = noise_reduction(err)
代码中的double_talk_detected至关重要。当用户和背景音乐同时发声时，AEC如果继续更新滤波器，会把用户语音也当作回声抵消掉，导致语音断续甚至完全消失。双讲检测可以基于参考信号与麦克风信号的相干性、能量比值或频域包络相似度来判断，检测到双讲后冻结滤波器系数，只保留已有的回声估计，等音乐或人声单独出现时再恢复更新。
语音处理IO的底层配置
iOS系统为实时语音应用提供了VoiceProcessingIO音频单元，它内部封装了自动增益控制、噪声抑制和回声消除。在AVAudioSession配置为playAndRecord加voiceChat后，系统通常会默认把inputNode挂载到VoiceProcessingIO。但有些时候，开发者为了接入自定义音频图，会手动创建AudioUnit，此时需要明确设置相关属性，否则可能意外绕过语音处理。
以下代码演示了如何手动创建VoiceProcessingIO并启用语音处理链路。其中kAUVoiceIOProperty_BypassVoiceProcessing设为0表示不绕过，kAUVoiceIOProperty_VoiceProcessingEnableAGC用来控制自动增益目标电平。不同iOS版本对这些属性的支持略有差异，但核心思路是确保语音处理没有被旁路。
AudioComponentDescription desc = {0};
desc.componentType = kAudioUnitType_Output;
desc.componentSubType = kAudioUnitSubType_VoiceProcessingIO;
desc.componentManufacturer = kAudioUnitManufacturer_Apple;
AudioComponent comp = AudioComponentFindNext(NULL, &desc);
AudioComponentInstanceNew(comp, &audioUnit);
UInt32 bypass = 0; // 0 表示启用语音处理，1 为绕过
AudioUnitSetProperty(audioUnit,
kAUVoiceIOProperty_BypassVoiceProcessing,
kAudioUnitScope_Global,
0,
&bypass,
sizeof(bypass));
Float32 agcTargetLevel = -3.0;
AudioUnitSetProperty(audioUnit,
kAUVoiceIOProperty_VoiceProcessingEnableAGC,
kAudioUnitScope_Global,
0,
&agcTargetLevel,
sizeof(agcTargetLevel));
在配置VoiceProcessingIO时，需要特别注意音频格式的采样率匹配。VoiceProcessingIO一般要求48kHz采样率，如果应用内音乐文件是44.1kHz，直接接入会导致重采样耗损和延迟增加。建议在音频会话中设置首选采样率为48000，同时把音乐解码后的PCM数据重采样到48kHz再送入音频图。这样避免了语音处理IO内部反复重采样，也能让AEC的参考信号与麦克风信号保持相同的时钟基准。
如果应用需要精细控制波束成形参数，iOS公开API并没有提供直接的多麦克风波束控制接口。实际工程中通常有两种做法：一是完全依赖系统VoiceProcessingIO内置的麦克风阵列处理，在系统层面已经完成了基本的波束成形；二是通过多通道输入接口获取原始麦克风阵列数据，在自己实现的DSP链路中完成波束成形和回声消除。后者灵活但复杂度极高，需要处理设备差异、麦克风一致性校准、实时性优化等问题。对于大多数语音通话或直播应用，优先依赖系统语音处理，再在应用层做轻量级后处理即可。
不同场景下的参数调优建议
参数调优不能一刀切。不同的使用场景下，回声路径长度、背景音乐音量、用户与设备的距离都不一样。对于手机外放场景，扬声器到麦克风的回声路径较短，滤波器阶数可以低一些，步长可以稍大；对于连接蓝牙音箱或AirPlay的场景，回声路径变长且存在无线传输抖动，滤波器需要更长阶数，双讲检测的判决阈值也要相应放宽。
在实际测试中，可以先用一段固定背景音乐播放，同时不说话，观察AEC收敛后的残留回声能量。正常情况下，残留回声应该比原始音乐低20dB以上。如果发现收敛慢或者残留明显，优先检查参考信号是否与麦克风输入存在固定的延迟偏移。可以给参考信号插入一个可配置的延迟补偿，从0到200毫秒扫描，找到残留能量最低的补偿值。这个值在不同外设上差异很大，因此建议把延迟补偿做成自适应估计，而不是写死。
下表给出几种典型场景的推荐配置，供测试时参考。所有数值都不是绝对标准，需要结合具体设备验证。
| 场景 | 参考信号延迟补偿 | AEC步长 | 双讲检测阈值 | 建议开启选项 |
|---|---|---|---|---|
| 手机外放，无后台音乐 | 10-30毫秒 | 0.2-0.4 | 中等 | mixWithOthers关闭 |
| 手机外放，应用内背景音乐 | 30-80毫秒 | 0.1-0.2 | 较高 | mixWithOthers开启 |
| 蓝牙音箱，后台播放 | 80-200毫秒 | 0.05-0.1 | 低 | mixWithOthers加allowBluetooth |
| 耳机通话，后台音乐 | 0-10毫秒 | 0.3-0.5 | 高 | mixWithOthers加allowBluetooth |
最后需要强调，语音突显模式带来的清晰度提升并非没有代价。开启VoiceProcessingIO后，CPU占用会明显增加，尤其是在低端设备上，如果同时进行波束成形和长滤波器AEC，可能会导致音频线程超时产生爆音。建议在性能较弱的设备上关闭部分非关键处理，例如降低滤波器阶数、使用更短的分析帧长，或者将波束成形交给系统处理而不在应用层重复实现。通过音频会话策略与DSP参数的联合调优，后台音频播放和语音清晰度可以同时得到保障。
AVAudioSession语音突显回声消除修改时间：2026-09-26 22:30:37