简介：这组资源是WebRTC音频处理中3A模块的最新可编译参考代码，面向音视频开发者和实时通讯技术学习者，帮助解决采集端语音质量优化问题。3A即自动增益控制（AGC）、噪声抑制（ANS）与回声消除（AEC），代码包涵盖agc、noise_suppression等核心源码、CMake构建配置及测试用wav/pcm音频样本，可直接在本地编译生成库或可执行文件，便于对照最新实现进行研究和二次开发。资源共249个文件，以c/cmake/h/make等源文件为主，并包含sample示例、构建脚本、说明文档与音频测试数据，整包约7.49MB。目前已有340人学习下载，适合正在钻研WebRTC音频链路、希望在实时通讯项目中优化语音清晰度的中高级开发者，也可作为排查回声、底噪、音量不稳等问题的参考起点。 搞实时音视频这两年，被用户反馈的“回声刺耳”“底噪轰头”“声音忽大忽小”折磨过之后，我算是把 WebRTC 音频 3A 这套东西彻底啃了一遍。网上搜“webrtc audio 3a 代码”出来的资源，要么是好几年前的老接口，跑起来全是编译错误，要么干脆是一堆半成品，根本没法直接参考。今天这篇不整虚的，直接从源码获取、环境搭建、编译参数、接口调用到排查经验一条龙梳理清楚，给一份真正能编译、能跑起来的最新参考代码路径和接入思路。适合已经拉过 WebRTC 源码但被庞大依赖劝退的人，也适合打算把 3A 算法移植到自研音频引擎或者 Android 音频 HAL 层的开发者。

先说结论：WebRTC 的 3A 并不神秘，它就是回声消除（AEC）、噪声抑制（NS）、自动增益控制（AGC）的合称。难的是代码结构复杂、依赖关系重、新旧版本 API 差异大。但只要理解它的数据流和编译套路，拿最新源码编译出可用的 3A 模块，是完全可行的事。

1. 入手前先搞懂：WebRTC 3A 到底在解决什么问题

1.1 三个核心模块的分工

3A 是三个算法模块的统称，它们处理的是实时音频通信里最典型的三个痛点。AEC 负责回声消除，解决扬声器播放出来的声音又被麦克风采集回去的问题；NS 负责噪声抑制，把风扇声、空调声、马路噪音这类底噪压下去；AGC 负责自动增益控制，保证说话声音大小时听感一致，不忽大忽小。

这三个模块在 WebRTC 内部是串行处理的，顺序基本是 AEC -> NS -> AGC，中间还会穿插一些残余回声抑制、瞬态处理之类的辅助模块。很多人接入时最容易犯的错，就是把这个处理顺序搞反，或者漏掉给 AEC 喂远端参考信号。只要参考信号没接对，后面 NS 和 AGC 调得再好，回声问题也永远解决不了。

1.2 为什么 3A 难？先理解信号流再读代码

很多人在网上找“3A 代码”，找到源码打开一看就傻眼了，几万行信号处理代码根本不知道从哪里看起。这是因为 3A 不是拿一个静态 wav 文件进去就能出效果的算法，它依赖实时信号流。AEC 需要同时输入两路信号：一路是近端麦克风采集的信号，一路是远端扬声器播放的参考信号。NS 需要实时估计噪声频谱，AGC 需要持续跟踪输入电平变化。

WebRTC 内部处理按 10ms 一帧切分，近端信号从 ProcessStream 接口进入，远端参考信号走 AnalyzeReverseStream 。读代码时建议不要一头扎进算法细节，先把数据流图理清楚。我自己遇到过不止一次，有人把远端参考信号当成普通文件循环播放喂给 AEC，结果回声一点都没消掉——原因就是参考信号和实际扬声器播放的数据对不上，AEC 没法估计正确的回声路径。

2. 源码获取：一份能编译的 3A 代码从哪里来

2.1 官方仓库与镜像选择

WebRTC 官方源码托管在 Google 的 googlesource 上，直接 git clone 是拿不到完整代码的。整个项目通过 depot_tools 管理依赖，里面带了一个叫 gclient 的同步工具。由于网络环境原因，直接从官方源同步代码经常卡住或者下载到一半失败。实际操作中，多数人会选择国内镜像或者第三方维护的 gitee 镜像仓库，先把 src 目录同步完，再手动跑 gclient sync 补依赖，这样能省去大量等待时间。

这里有一个非常重要的认知：WebRTC 不是一个普通的 git 仓库，它依赖几十个第三方库，包括 abseil-cpp、libyuv、opus、ffmpeg 等。所以单独 clone src 目录是编译不了的，必须通过 gclient 把整个依赖树拉下来。

2.2 拉取源码的完整命令流程

先准备 depot_tools，然后把它的路径加到环境变量里，再创建一个工作目录执行同步。

export PATH=$PATH:/path/to/depot_tools
mkdir webrtc-build
cd webrtc-build
gclient config https://webrtc.googlesource.com/src
gclient sync --with_branch_heads --with_tags -vv

这里有几个细节需要特别注意。 --with_branch_heads 这个参数必须带上，否则后面想切换到稳定分支的时候会发现找不到对应的 refs。sync 过程中如果报错，大概率是 python 环境有问题。WebRTC 构建对 python 版本要求比较严格，目前主流用 python3，但如果系统里装的是过新的版本，某些历史脚本还是会报语法错误。报错时先检查 python 版本，再检查磁盘空间和网络连接，不要盲目重试。

提示： gclient sync -vv 虽然输出信息非常多，但排查下载中断的问题时非常有用。静默模式下看到报错也难定位，先开详细日志跑一遍。

2.3 版本选择：追最新还是挑稳定

WebRTC 主干的 API 变动非常快，今天编译通过的代码，过两周接口可能就变了。所以做真实项目，我更推荐挑一个稳定的 branch。具体版本号不用死记，重点看 modules/audio_processing/include/audio_processing.h 里有没有 AudioProcessing::Config 结构体。

从 M95 之后的大版本开始，3A 的统一配置入口就走 Config ，老 API SetExtraOptions 基本不再需要碰。挑版本时另一个判断标准是看 gain_controller2 是否已经默认启用。如果你手上的业务对双讲场景要求高，优先选带完整 AEC3 实现的版本，不要选 mobile_mode 默认开启的版本，否则回声消除的表现会明显偏弱。

3. 编译实践：让 3A 模块在本地跑起来

3.1 编译环境准备

编译 WebRTC 不太推荐在虚拟机上搞，模块多、静态库链接大、I/O 压力高，虚拟机里编译一次的时间能让人怀疑人生。建议使用 Linux 或者 macOS，内存 8G 以上，磁盘留足 30G 以上。Windows 也能编，但需要装 Visual Studio 的 C++ 工具集，环境配置要更仔细。

还有一条必须提醒：不要用太老的编译器。WebRTC 对 C++ 标准要求不低，gcc 9 以下大概率会挂一堆模板编译错误。CMake 版本、ninja 版本也要尽量用官方文档推荐的版本，不然某些模块会莫名编译失败。

3.2 GN 参数配置详解

WebRTC 使用自己的 gn/ninja 构建体系，和 CMake 生态完全是两套。生成构建文件的命令长下面这样：

gn gen out/default --args='is_debug=false is_component_build=false rtc_include_tests=false rtc_build_examples=false rtc_use_h264=false rtc_enable_protobuf=false use_custom_libcxx=false target_cpu="x64"'

我逐个解释一下这些参数的实际作用，方便你按需调整。

is_debug=false 编译 release 版本，体积更小、性能更优，调试 3A 算法时经常要打开 is_debug=true ，但编译时间会明显更长。 is_component_build=false 表示把所有模块打成一个静态库，方便后续链接到自己的工程；如果设成 true，模块会拆成多个动态库，适合开发期增量编译但部署麻烦。 rtc_include_tests=false 和 rtc_build_examples=false 都是为了少编几百个测试文件和示例代码，能显著缩短编译时间。 rtc_enable_protobuf=false 关掉不需要的序列化依赖，实时音频处理根本用不到。

这些参数不是拍脑袋写的。每关掉一个不需要的模块，编译时间都能缩短好几分钟。实际操作时，我习惯先用最小参数集合编一次，确认整个流程跑通，再逐步打开自己需要的特性，这样排查编译错误更快。

3.3 编译目标和产物说明

整个 WebRTC 工程非常庞大，直接 ninja -C out/default 全部编译，等的时间会非常久。只编译 3A 相关的目标就够了，命令如下：

ninja -C out/default api:rtc_audio_processing

这个目标会把 audio_processing 模块及其依赖的 rtc_base、common_audio 等基础库一起编出来。最终产物是几个 .a 文件（Linux 下是静态库，macOS 下是 .a 或者 .dylib ）。这些库包含了完整的 AEC3、NS、AGC 实现，不需要也不应该去改里面的算法代码。你要做的，是在自己的工程里调用 AudioProcessing 接口，把音频数据一帧帧送进去，再把处理后的数据拿出来。

4. 接入自己的音频前后处理链路

4.1 最推荐写法：用 Config 结构体配参

不要再去翻那些使用 SetExtraOptions 的老 demo 了，新版本标准姿势是创建 AudioProcessing 实例，然后填充 Config 结构体。具体代码如下：

#include "modules/audio_processing/include/audio_processing.h"

webrtc::AudioProcessing* apm = nullptr;
webrtc::AudioProcessingBuilder builder;
apm = builder.Create();

webrtc::AudioProcessing::Config config;
config.echo_canceller.enabled = true;
config.echo_canceller.mobile_mode = false;  // 桌面双讲场景，mobile_mode 要关掉
config.noise_suppression.enabled = true;
config.noise_suppression.level = webrtc::NoiseSuppression::Level::kHigh;
config.gain_controller1.enabled = false;    // 新旧 AGC 互斥，启用 Gc2 就要关 Gc1
config.gain_controller2.enabled = true;
config.gain_controller2.fixed_digital.gain_db = 6.f;
apm->ApplyConfig(config);

这里有个特别容易踩的坑： gain_controller1 和 gain_controller2 默认互斥。开了 Gc2 再开 Gc1，API 会触发告警甚至崩溃。Gc2 的固定增益 fixed_digital.gain_db 设置为 6dB 比较稳，适合大多数通话场景。如果业务需要自适应增益，那就得用 Gc1 的 adaptive_digital ，但 Gc1 代码在 legacy 目录里维护，新工程不建议碰。

4.2 10ms 音频帧处理完整流程

在实时通话链路里，你拿到的麦克风数据和远端参考数据采样率可能不一样。比如本地用 48kHz 采集，网络编解码走 16kHz。WebRTC 3A 支持 8kHz、16kHz、32kHz、48kHz 输入，但推荐整个链路统一用 48kHz 处理，少一步重采样就少一个出问题的环节。

处理一帧数据的代码框架：

const int kSampleRate = 48000;
const int kNumChannels = 1;
const int kChunkSizeMs = 10;
const int kChunkSize = kSampleRate / 100 * kChunkSizeMs;

webrtc::StreamConfig config_in(kSampleRate, kNumChannels, false);
webrtc::StreamConfig config_out(kSampleRate, kNumChannels, false);

// 远端参考信号，必须是扬声器实际播放的数据
apm->AnalyzeReverseStream(remote_data, config_in, config_out);
// 近端麦克风信号，处理后写回发送缓冲区
apm->ProcessStream(near_data, config_in, config_out, near_data);

很多人在这一步犯迷糊：AEC 里的参考数据和最终要发到网络对端的数据是同一个东西吗？答案是不是。AEC 参考的是本地扬声器实际播放的那一路信号，这路数据在播放前可能经过混音、音量调整、硬件音效处理。如果你拿网络对端解码后的数据当参考，回声永远消不干净，因为 AEC 估计的是扬声器到麦克风的声学路径，参考信号必须和真实播放信号保持时间对齐。

4.3 把 3A 模块精简到自己的工程

完整编出来的 WebRTC 是几百 MB 的库，生产环境不一定需要全量引入。减少交付物最省事的方式是直接链静态库，但更彻底的做法是把 modules/audio_processing 底下的源码提取出来，同时带上 rtc_base、common_audio 等必要依赖。

提取源码时最痛苦的就是处理依赖关系，好在官方构建系统已经把模块边界划分得很清楚。如果你只是想先跑通一个“能编译的 3A 参考”，建议先用静态库方式做概念验证，跑通后再逐步裁剪。千万别一上来就手工往自己工程里拷源码，依赖问题会让你改到怀疑人生。

5. 新版本 API 变化与应用场景分析：不止 WebRTC

5.1 API 演进的几个关键点

从 M90 开始，WebRTC 把 AEC3、APM 的内部接口大量重构成 config 结构体驱动。主调用方不再需要手动画处理链拓扑， AudioProcessingBuilder 还可以塞入 CapturePostProcessing 之类的定制模块。整体趋势是：对外接口收敛，内部实现下沉。

如果你手头是老代码，需要重点检查三处。第一， Create() 是否还是 New() ，新版本统一用 AudioProcessingBuilder().Create() 。第二， Config 结构体字段是否改名，比如 noise_suppression.level 的值枚举变成 kLow/kModerate/kHigh/kVeryHigh 。第三， GainController2 是否默认被使能，新版构建里 Gc2 默认状态有变化，务必在 ApplyConfig 里显式声明。

5.2 3A 的影响范围：从浏览器到嵌入式

3A 并不仅仅存在于 WebRTC 浏览器链路里。现在做 Android 音频 HAL、自研会议系统、直播连麦的人，很多都在借鉴这套处理逻辑。即使完全不集成 WebRTC，AEC3 的非线性处理思路、NS 的噪声谱估计方法、AGC2 的固定增益和自适应增益混合策略，都是可以直接参考的信号处理范式。

很多声卡驱动或者底层音频 HAL 在做效果处理时，算法思想也有 3A 的影子。比如遇到“realtek audio console”或者“Intel High Definition Audio”这类名词时，它们底层也会有回声消除和噪声抑制的开关选项，只是实现方式偏向固定参数，不像 WebRTC 这样可以细粒度控制。理解 WebRTC 3A 之后，再去看这些 HAL 层配置，思路会清晰很多。

6. 常见踩坑与排查速查表

实际操作中常见的坑，我整理成了一张速查表，方便你直接对照排查。

现象	可能原因	解决办法
AEC 没效果，回声很大	参考信号没喂或喂错	确认 AnalyzeReverseStream 收到的是本地扬声器实际播放的数据
AGC 声音忽大忽小	同时开了 Gc1 和 Gc2 两个 AGC	新旧 AGC 互斥，只能二选一
NS 把语音也抑制了	噪声抑制等级过高	先换 kModerate，别一上来就用 kVeryHigh
编译报错找不到 api/ 目录	工程不完整，缺少 WebRTC 根目录模块	用 gclient sync 同步，不要直接 clone src
运行崩溃或者有毛刺	采样率/声道数与实际数据不一致	整个链路统一用 48kHz 单声道
双讲场景 AEC 吃人声	mobile_mode 被设为 true	桌面会议场景改成 false
处理延迟越来越高	一次送入 ProcessStream 的数据不是 10ms 对齐	严格按 10ms 整数倍切帧再送
声音发闷	参考信号和近端信号重复做了重采样	保证两条链路采样率一致，不要各重采样一次

其中有两个坑我实测踩得最多。一个是采集数据先做了重采样再进 3A，导致 AEC 的参考信号和近端信号时间对齐不上，回声怎么都消不掉。另一个是没有严格按照 10ms 对齐处理时长，WebRTC 内部默认按 chunk 处理，如果一次送给 ProcessStream 的帧长不是 10ms 的整数倍，处理结果就会带滤波毛刺，听感上像隔了层纱。

我个人在实际操作中的体会是，WebRTC 的 3A 代码不是只能在浏览器里用，把它理解成一整套音频前处理的参考实现之后，思路一下就打开了。以我自己把 AEC3 算法移植到自研嵌入式音频处理模块的经历来说，调试阶段最大的助力就是拿官方测试数据一条条跑，观察每一步频谱图的变化。最后再分享一个小技巧：调试 AEC 时，建议先关掉 NS 和 AGC，单独验证回声消除效果。如果 AEC 本身没消干净，后面两个模块会把问题放大，你会误以为是 NS 参数没调好。这个顺序搞对，能省下至少一周的排查时间。

本文还有配套的精品资源，点击获取