Opus是个不错的选择。它声称是互联网（即具有不一致延迟的有损传输）音乐和语音流应用程序的卓越解决方案。具体来说，它在重要的时候提供了对编码延迟的严格控制。它基于之前两种编解码器的技术：由 Skype 开发的用于语音传输的SILK和CELT，一种为低延迟流音频开发的编解码器。

Opus 的一个很好的方面是它是一个开放标准，因此提供了一个参考实现，其中包含用于浮点和定点计算的源代码。它还声称支持多种架构，包括 x86、ARM 和 MIPS，这可能很有用。

就质量而言，Opus 和其他音频编解码器（如 AAC 或 MP3）之间有许多详细的比较。这是一个似乎很好地总结了它的情节：

基本上，Opus 的制造商在广泛的比特率范围内向其竞争对手声称拥有卓越的音频质量。尤其是在 16-32 kbps 的相当低的比特率范围内，它目前似乎没有对等的。此页面有许多可以在浏览器中运行的实时测试，展示了它在语音和音频方面的性能、对丢包的鲁棒性以及动态更改比特率（以及音频质量）的能力。

Speex用于实时聊天已经有一段时间了。它专为语音而设计。一些更高级的语音编解码器基于它。Speex 的优势在于它是免费的，源代码随时可用，并且在编码和解码方面速度很快。压缩比是可变的，但出于质量原因，您最有可能使用大约 10:1 的设置。

我已经有一段时间没有使用过 Speex 并且不知道代码当前的位置。我记得不得不使用较旧的版本，因为较新的版本广泛使用了 C++新版本，并且不适合运行它的系统协处理器环境使用。

您没有提及您正在流式传输的源是实时的还是预先录制的。是否需要编码和解码都很重要。编码通常比解码花费更长的时间。

同样重要的是您是否总是从头开始玩，或者可以跳到前面或后面的任何点。许多压缩方案依赖于来自先前解码的块的“状态”，这可能会导致查找问题。（这将是一个评论，但我是一个卑微的新手。）