Opus 编码协议如何在低带宽下保持音质与低延迟
AudioRelay 不在网络上裸传 PCM 原始音频——它用 Opus 编码 压缩后再传。Opus 是 Google 主导、IETF 标准化的实时语音/音频编码协议，专门为低延迟、高压缩比场景设计。
为什么用 Opus 不用 PCM
| 编码 | 同样 48kHz 采样率的带宽需求 | 延迟 | 音质 |
|---|---|---|---|
| PCM 16bit 立体声 | ~1.5 Mbps | 极低 | 原始无损 |
| Opus 48kHz 立体声 @ 96kbps | 96 kbps | 极低（20ms 级） | 听起来几乎和 PCM 一样 |
| Opus 48kHz 立体声 @ 64kbps | 64 kbps | 极低 | 好于 AAC 64kbps |
| AAC 48kHz @ 128kbps | 128 kbps | 中等（编码延迟 100ms+） | 好但编码延迟高 |
AudioRelay 默认用 Opus 在 64~96kbps 之间动态调整——只需要 PCM 十分之一的带宽，音质几乎不损失。
Opus 的两个关键优势
1. 编码延迟极低
Opus 设计目标就是实时通信（和 WebRTC 同源）。一帧 Opus 编码只需几毫秒——在 AudioRelay 的 25ms Wi-Fi 延迟里，编码/解码只占不到 2ms，几乎可以忽略。
如果用 AAC 或 MP3（编码延迟 100ms+），光编码就超过了 AudioRelay 的总延迟——那低延迟模式就白做了。
2. 比特率自适应
Opus 可以在保持低延迟的同时，根据网络状况动态调整比特率。网络好 → 自动升到高码率（96~128kbps），网络差 → 自动降到低码率（48~64kbps）。用户不会感知到，AudioRelay 自动做。
AudioRelay 里 Opus 是怎么用的
开发者 Asapha 在社区帖里给出了完整链路：
其他 App 播放音频 → Windows WASAPI Mix（系统混音）
→ AudioRelay Desktop → 格式转换 → Opus 编码 → 网络
→ AudioRelay Android → Opus 解码 → Android 音频输出可以看到：
- 只有 Opus 编码这一层是压缩的，前后都是 PCM 原始音频
- 编码/解码各一次，加起来延迟只有几毫秒
- AudioRelay 没有把 Opus 解码后的音频再编码回去——直接喂给 Android 音频引擎
和蓝牙的对比
蓝牙 A2DP 音频也是用编码的（SBC、AAC、aptX），但：
- 蓝牙有 链路管理 的额外延迟（连接建立、缓冲区协商）
- 蓝牙的缓冲是不可调的（协议固定 100~200ms）
- AudioRelay 的 Opus Buffer 你可以调（Low 30ms 起步）
这就是为什么同样是 Wi-Fi / 蓝牙，AudioRelay 的实际延迟能做到 25ms 而蓝牙 SBC 要 100ms+。
音质调优选项
Opus 编码本身不需要用户调什么——AudioRelay 自动选最佳参数。但有一个间接影响的：
Windows 采样率设到 48kHz：Opus 原生适配 48kHz，Windows 默认如果是 44.1kHz 或更低，AudioRelay 要额外做采样率转换 → 轻微音质损失 + 额外 CPU 开销。详见 采样率 48kHz 设置。
什么时候 Opus 不够好
极少数情况下（比如监听混音、母带制作），你可能感觉 Opus 有可感知的音质损失。这时候 AudioRelay 没有提供 PCM 原始音频传输选项——Opus 是硬编码的。对于「母带级监听」这种需求，应该用有线连接或专业音频接口，不应该指望 Wi-Fi 传输。