对讲方案选型、硬件链路、音频引擎、RTP/WebRTC，到弱网、AEC 与量产测试的完整技术拆解
内容提要
本文系统阐述嵌入式音频对讲的产品级实现方案，涵盖半双工/全双工、局域网/公网等需求选型，推荐“独立音频引擎+可替换协议层”架构。核心涉及ALSA硬件层、AEC/NS/AGC算法、Opus编码、RTP/Jitter Buffer及WebRTC/SIP协议，强调声学结构、时钟同步、弱网恢复和诊断测试，并给出分阶段实施路线与验收清单。
延伸解读
选型决策树：从需求到方案
文章给出了清晰的选型决策树：先判断是否固定局域网，再考虑是否需要第三方互通，最后决定是否公网互通。这提醒开发者，方案选择应基于具体场景，而非盲目追求最新技术。例如，局域网工业对讲可优先考虑轻量的RTP/UDP，而公网设备对App则更适合WebRTC。
AEC：全双工对讲的核心挑战
AEC是全双工对讲最关键的模块，文章强调参考信号应取自即将送入扬声器的PCM，而非压缩数据。同时，声学结构比算法参数更重要，非线性失真难以完全消除。开发者需关注延迟对齐、双讲处理，并建立覆盖单讲、双讲、音量变化等场景的测试矩阵。
时钟同步与弱网恢复：不可忽视的细节
文章指出，播放与采集时钟不同步会导致延迟累积和回声恶化，建议使用同一音频PLL或异步重采样补偿。弱网恢复需处理Wi-Fi切换、IP变化等场景，并避免旧媒体线程未停止、旧RTP包进入新会话等问题。这些细节往往决定产品稳定性。
实施路线：分阶段降低风险
文章推荐分阶段实施：先本地ALSA双工，再局域网PCM/RTP原型，然后加入Opus和AEC，最后接入协议。这样可逐步验证硬件、算法和网络，避免一次性集成WebRTC和AEC导致问题难以定位。每个阶段都有明确验收标准，有助于控制项目风险。
Q&A
嵌入式音频对讲产品选型时，如何确定是采用半双工还是全双工？
半双工类似传统对讲机，同一时刻只允许一个方向发送，软件和声学难度较低，适合高噪声、工业调度和成本敏感产品；全双工类似电话，双方可同时讲话，用户体验自然，但必须处理回声、双讲、时钟漂移等问题，适合门禁、机器人、远程协作等场景。
在嵌入式音频对讲中，AEC（回声消除）的参考信号应该从哪里取？
AEC的参考信号应尽量接近真正送入ALSA Playback的PCM数据，即经过解码、混音、音量调整等处理后的最终播放数据。错误做法包括使用Opus压缩数据、网络刚收到但未解码的数据，或参考信号之后又进行大幅音量变化而不通知AEC。
嵌入式音频对讲中，为什么推荐使用Opus编码而不是AAC？
Opus专为实时语音和互联网传输设计，支持8-48kHz采样率、2.5-60ms帧长、PLC、In-band FEC、动态码率等，适合弱网和低延迟场景；AAC更适合音乐、广播、存储等，算法延迟高，丢包隐藏能力弱，不适合实时双向对讲。
在RTP传输中，Sequence Number和Timestamp分别有什么作用？
Sequence Number用于检测丢包、乱序和重复包，确保按正确顺序播放；Timestamp表示媒体时间，用于播放调度、抖动估计和音视频同步。对于Opus，时间戳时钟按48kHz递增，20ms包对应960个时间戳单位。
嵌入式音频对讲中，如何应对网络抖动和丢包？
采用自适应Jitter Buffer动态调整缓存深度，结合PLC（丢包隐藏）和Opus In-band FEC进行丢包恢复，同时通过RTCP反馈网络状态，必要时降低码率。不能简单增加大Buffer，否则会增加延迟。
在嵌入式Linux平台上，实现全双工对讲时，如何避免时钟漂移问题？
优先使用同一个Audio Codec和音频PLL，使Capture和Playback共享时钟域；若无法同步，则需采用异步重采样、Sample Slip或时间伸缩等方法进行补偿，并通过队列水位监测漂移情况。
对于公网设备对App/浏览器的对讲产品，推荐采用哪种技术方案？
推荐采用WebRTC技术，包括DTLS-SRTP加密、ICE/STUN/TURN穿透、Opus编码等，配合自建信令（如WebSocket）或使用云平台P2P SDK。嵌入式端可根据资源选择完整libwebrtc、libdatachannel+自研音频引擎、GStreamer webrtcbin或托管WebRTC SDK。
嵌入式音频对讲产品开发中，如何设计诊断和测试方案？
需要支持PCM Dump（如capture_raw.pcm、render_reference.pcm等），统计网络指标（丢包率、抖动、RTT等）和音频指标（XRUN、削顶率、AEC ERLE等），进行端到端延迟Trace，并建立功能测试、音频链路测试、AEC测试、网络仿真测试和长稳测试等。
