会议音频治理：从回声检测到啸叫抑制

会议室中的麦克风、扬声器及其自带算法能力各不相同。有些设备已经具备较好的回声消除能力，有些设备尚未适配，也可能在实际使用中表现不稳定。软件回声消除（AEC）的默认开关，需要结合设备条件确定。

围绕这类问题，我们将音频设备适配白名单、会前回声检测和会中回声监测放在一起设计：先依据已知设备能力设置默认行为，再通过实际检测补充判断，并把检测结果交给用户或业务选择处理方式。

此外，同一空间内多台设备同时入会、开启麦克风和扬声器，也可能产生刺耳的啸叫。针对这类问题，我们补充了啸叫检测与抑制，让底层自动处理与业务侧提示能够配合起来。它与回声治理共同服务于会议音频体验，处理对象和响应方式则需要分别明确。

设备适配，确定默认处理方式

白名单记录经过适配的麦克风、扬声器及其音频处理能力。对于硬件 AEC 能力足够的已适配设备，默认关闭软件 AEC，让设备按照适配后的配置工作。

白名单体现的是已经核实的设备能力。未进入名单的设备仍可能自带 AEC，因此还需要检测，了解当前麦克风与扬声器组合的实际表现。

设备切换也需要纳入这个机制。插入或更换外设后，底层算法配置与业务界面的开关状态应保持一致，让用户能够理解当前使用的是哪种处理方式。

会前检测通过播放测试音频、由当前麦克风采集声音，判断这组设备是否存在残留回声，以及回声消除能力的表现。

检测结果可以帮助用户在会议开始前检查或更换设备；对于软件 AEC 可以启用的设备，也可以据此考虑开启软件处理。这样，已能提前发现的问题就有机会在正式沟通前得到处理。

这一步补充了设备适配的覆盖范围：同一类能力需要同时考虑已有的适配结论和当前设备组合的检测结果。

会前检测通过后，会中仍然需要持续监测。设备在真实使用中可能出现回声处理不稳定，单次测试难以代表整场会议的状态。

RTC 检测到回声后，通过状态码将结果告知业务。业务结合设备适配情况和软件 AEC 的开关状态，再决定怎样响应。对未适配且软件 AEC 尚未开启的设备，可以据此决定是否启用软件处理。

这里还需要明确检测信号的含义：监测的是硬件本身的回声处理情况，而非软件处理后的最终声音。如果软件 AEC 已经生效，硬件层出现残留回声，对端未必实际听到了回声。业务需要结合当前处理状态解释信号，避免将检测结果直接等同于用户受到的影响。

一个典型场景是，会议室已经使用会议设备收音和播放声音，又有人用手机加入同一场会议，却没有关闭手机的麦克风和扬声器。另一个场景是，多位参会者在距离较近的位置分别入会，同时使用外放和麦克风。声音在设备之间反复进入采集与播放链路，形成反馈，可能变成严重失真、越来越刺耳的啸叫。

用户有时也会把这种问题描述为“有回声”。产品侧需要继续区分：是当前设备的回声处理能力不足，还是同一空间内多台设备形成了声音反馈。两者可以放在同一个音频治理主题下，具体处理动作却不能直接套用。

在支持啸叫抑制的场景中，由底层进行抑制；如果啸叫已被抑制，就不再触发警告。对于未能被抑制的啸叫，再通过设备警告将结果通知业务，由业务提示用户，并引导关闭相关设备的麦克风和扬声器。

这样，检测与用户提示之间多了一层明确判断：当前问题是否还需要业务介入。底层能够处理的问题，不必都转成一次打断用户的提示；需要改变设备使用方式时，则要把检测结果接到具体操作上。

检测和抑制的适用范围也需要分开说明。能够检测啸叫的业务场景，不一定都启用了同样的抑制能力。接入方需要知道当前场景具备什么能力，以及收到警告后应采取什么动作，避免把“支持检测”理解成所有问题都会被自动解决。

设备适配提供已知条件下的默认配置，会前检测帮助提前识别问题，会中监测补充运行过程中的变化；啸叫检测与抑制则处理多设备共同使用时的声音反馈，并将需要进一步处理的情况交给业务。

这些能力的共同点，是检测结果必须结合处理状态解释。回声监测发现硬件残留回声时，软件 AEC 可能已经保护了对端体验；啸叫被底层抑制后，也不需要再让用户重复处理。发现异常、异常是否已经得到处理，以及是否需要用户行动，是三个需要分别回答的问题。

设计这类音频能力时，检测对象、结果含义与可采取的动作需要一起明确。RTC 提供设备识别、检测、算法处理和状态反馈，业务根据这些信息组织开关、提示与处理策略，才能让不同阶段的能力共同服务于会议体验。