自部署 LiveKit 的降噪与回声消除：能力边界与工程选型

在实时音视频、在线会议和 Voice Agent 场景里，“降噪”和“回声消除”经常被一起讨论。很多团队在自部署 LiveKit 时，也会自然地提出一个问题：LiveKit Server 到底有没有内置降噪模型？回声消除又是靠什么完成的？

答案需要先拆开看。

自部署 LiveKit Server / SFU 本身主要负责媒体转发，不内置通用降噪模型，也不负责常规意义上的回声消除。 在实际系统里，降噪通常发生在客户端、Agent、SIP 网关或外部音频处理链路中；回声消除则更依赖采集端，也就是浏览器、移动端、桌面端或 Agent 的音频处理模块。

本文讨论的是自部署 LiveKit 场景，不包含 LiveKit Cloud 托管能力的默认可用性。

核心结论

自部署 LiveKit 的音频增强能力，可以先按下面这张表理解：

如果你部署的是自己的 LiveKit Server，不应该期待 SFU 自动完成降噪或回声消除。更合理的架构是：在音频进入房间之前完成采集端处理，或在 Agent 消费音频流时接入独立的音频增强模块。

为什么 LiveKit Server 不直接做这些处理？

LiveKit Server 的核心角色是 SFU，也就是 Selective Forwarding Unit。它接收参与者上传的音视频轨道，再根据订阅关系、网络状态和转发策略，把媒体流分发给其他参与者。

这种架构的价值在于低延迟、低 CPU 成本和较好的扩展性。相应地，SFU 通常不会对每一路音频持续进行复杂的解码、分析、降噪和再编码。否则，系统成本和端到端延迟都会明显上升。

回声消除尤其不适合放在 SFU 上统一处理。一个标准 AEC 系统至少需要两路信号：

• near-end：麦克风采集到的本地声音，其中可能包含本地说话声、环境噪声和扬声器回声。
• far-end / reverse stream：本机扬声器正在播放的远端音频，用作回声参考信号。

LiveKit Server 位于网络中间，通常拿不到用户设备扬声器实际播放后的声学参考，也不了解本地设备的延迟、音量、麦克风位置和房间反射环境。因此，AEC 最理想的位置通常是音频采集端。

自部署场景下的降噪方案

1. WebRTC 内置降噪

最基础的方案，是使用浏览器或 SDK 暴露的 WebRTC 音频约束：

{
  echoCancellation: true,
  noiseSuppression: true,
  autoGainControl: true
}

其中，noiseSuppression 是浏览器或平台音频栈提供的背景噪声抑制能力。它的优点是启用简单、延迟低、不需要额外服务；缺点是效果受浏览器、操作系统和设备影响较大，也无法替代专门的语音增强模型。

这个方案适合普通会议、浏览器接入、轻量语音应用，以及对部署复杂度比较敏感的场景。如果目标只是减少键盘声、风扇声和轻微环境噪声，可以先从这里开始。

2. ai-coustics 插件

如果使用 LiveKit Agents，并且希望在 Agent 侧做更强的音频增强，自部署场景下比较现实的官方生态方案是 ai-coustics。

它提供的模型大致可以分为两类：

示例代码如下：

from livekit.plugins import ai_coustics

noise_cancellation = ai_coustics.audio_enhancement(
    model=ai_coustics.EnhancerModel.QUAIL_VF_S,
    auth=ai_coustics.Auth.ai_coustics_api(
        license_key="YOUR_AI_COUSTICS_API_KEY"
    ),
)

需要注意的是，ai-coustics 不是 LiveKit Server 内置能力，而是独立插件和独立授权。它更适合 Voice Agent、客服、语音识别前处理等场景，尤其是需要在进入 STT 之前压低背景人声或环境噪声时。

3. Krisp 官方降噪

LiveKit 文档中可以看到 Krisp NC、Krisp BVC、Krisp BVCTelephony 等能力：

• Krisp NC：背景噪声抑制。
• Krisp BVC：Background Voice Cancellation，用于抑制背景人声。
• Krisp BVCTelephony：面向电话场景的背景人声抑制。

但在完全自部署 LiveKit Server 的场景里，Krisp 官方增强降噪通常不能简单当作本地模型直接启用。LiveKit 的官方 Krisp 集成多数依赖 LiveKit Cloud 的 transport、auth 或授权链路。

换句话说，如果你运行的是自己的 LiveKit Server，并且不使用 LiveKit Cloud，通常不能默认把这些 Krisp 能力视为可用的自带模型。是否能使用，需要单独确认授权方式和部署形态。

4. 自研或第三方离线模型

如果目标是完全离线、可控、无外部授权依赖，可以在客户端或 Agent 侧接入第三方模型，例如：

• RNNoise
• DeepFilterNet
• DTLN
• 自研 ONNX / TorchScript 模型
• WebAssembly 音频处理模块

这类方案的优势是可控性强，能够满足私有化部署要求；代价是工程复杂度更高。团队需要自己处理音频帧格式、采样率、延迟预算、CPU/GPU 占用、模型加载、异常回退和质量评估。

在 LiveKit Agents 中，常见做法是在音频进入 STT 或业务逻辑之前，对 PCM frame 做一层预处理。

自部署 LiveKit 的回声消除依赖什么？

回声消除和降噪不同，它通常不是一个“选哪个模型”的问题，而是一个“音频采集链路是否完整”的问题。

在自部署 LiveKit 中，AEC 主要来自以下几类实现。

1. 浏览器 WebRTC AEC / AEC3

如果用户通过 Chrome、Edge、Safari、Firefox 等浏览器加入 LiveKit 房间，回声消除通常由浏览器的 WebRTC 音频模块完成。

在 Chromium/WebRTC 体系中，现代回声消除主要来自 WebRTC Audio Processing Module 中的 AEC/AEC3。它不是 Krisp，也不是 ai-coustics，而是以传统 DSP 为主的声学回声消除算法。

它的基本工作过程是：

1. 浏览器知道当前设备正在播放哪些远端音频。
2. 浏览器把远端播放音频作为参考信号。
3. 麦克风采集到本地声音后，AEC 算法估计其中的回声成分。
4. 算法从麦克风信号中尽量抵消远端回声。

这也是 AEC 通常应该放在客户端的原因：只有客户端最清楚扬声器播放了什么、麦克风采到了什么、设备延迟是多少，以及声学路径如何变化。

2. LiveKit Agent 的 AudioProcessingModule

如果在 Agent 里自行处理音频，LiveKit Python SDK 提供了 AudioProcessingModule 这类能力。它底层使用 WebRTC audio processing，支持：

• Echo Cancellation
• Noise Suppression
• Automatic Gain Control
• High-pass Filter

AEC 的关键不只是处理麦克风输入，还要提供 reverse stream，也就是远端参考音频。LiveKit Python APM 中的 process_reverse_stream() 就是为这个目的准备的。

如果没有正确的 far-end 参考信号，AEC 很难稳定工作。

3. iOS / macOS 的系统级 AEC

在 Apple 平台上，真机通常会使用系统的 Voice Processing I/O 音频单元来处理回声消除、增益控制和部分语音增强。这是平台级能力，整体表现通常比较稳定。

需要注意的是，模拟器和真机行为可能不同。做音频质量验证时，应该以真机为准。

4. Android 的系统或 WebRTC AEC

Android 上的情况更复杂，因为不同厂商、不同机型的音频 HAL 和硬件 AEC 实现差异较大。实际项目中，Android AEC 可能来自：

• WebRTC 软件 AEC
• Android 系统提供的 AcousticEchoCanceler
• 设备厂商的硬件或固件处理

因此，Android 端需要做更多真机测试，不能只依赖单一设备的验证结果。

工程实践建议

普通会议

如果是普通音视频会议，自部署 LiveKit Server 搭配浏览器客户端时，通常可以先开启浏览器音频约束：

{
  echoCancellation: true,
  noiseSuppression: true,
  autoGainControl: true
}

这已经能覆盖很多常见场景。只有当用户环境很吵、语音识别准确率要求很高，或者存在多人背景说话干扰时，再考虑更强的降噪或语音隔离方案。

Voice Agent / 语音识别

如果音频最终要进入 STT，建议把音频增强当作独立链路评估：

• 浏览器端先开启 WebRTC AEC/NS/AGC。
• Agent 侧根据需要接入 ai-coustics 或自研降噪模型。
• 避免重复叠加多个强降噪模型，以免造成语音失真。
• 同时评估 STT 结果、端到端延迟和主观音质，不只看单一指标。

电话 / SIP 场景

电话场景的回声来源更复杂，可能来自终端、网关、PBX、运营商链路或免提设备。

如果使用 LiveKit SIP，自部署 LiveKit 仍然不意味着 SFU 会自动处理所有回声。电话侧更常见的处理位置包括：

• 话机或软电话
• SIP 网关
• PBX
• DSP 设备
• 独立音频处理服务

对于 SIP 场景，建议先定位回声来源，再决定是在终端、网关还是 Agent 侧处理。

常见误区

误区一：LiveKit Server 会自动降噪

不会。LiveKit Server 主要做媒体转发。降噪要在客户端、Agent 或额外音频处理链路中完成。

误区二：回声消除可以放到 SFU 上统一做

理论上可以做某些服务端音频处理，但标准 AEC 强依赖本地扬声器参考信号和设备声学路径。实际工程中，AEC 最适合放在采集端。

误区三：Krisp 模型可以直接用于任意自部署 LiveKit

通常不行。LiveKit 官方 Krisp 集成多和 LiveKit Cloud 授权链路绑定。完全自部署时，要单独确认授权和可用性。

误区四：降噪越多越好

不是。多层降噪叠加可能导致语音发闷、断字、金属音，甚至降低 STT 准确率。实时语音系统里，音质、延迟和稳定性要一起看。

推荐选型

总结

自部署 LiveKit 的音频增强，不是在 LiveKit Server 里打开某个模型开关那么简单。更准确的理解是：

• LiveKit Server / SFU 不内置通用降噪模型，也不负责常规回声消除。
• 降噪可以使用 WebRTC 内置能力、ai-coustics 插件，或自研/第三方离线模型。
• Krisp 官方增强降噪多数依赖 LiveKit Cloud，不能默认视为完全自部署可用。
• 回声消除主要依赖 WebRTC AEC/AEC3、系统音频栈或 Agent APM，应尽量靠近音频采集端。

如果目标是普通会议，先用客户端 WebRTC 音频处理能力即可。如果目标是高质量 Voice Agent 或嘈杂环境下的语音识别，再把 Agent 侧音频增强作为独立模块设计、压测和评估。