流式传输音频时的 UDP 数据包大小/延迟权衡？

Question

我正在构建一个通过 udp 在线流式传输实时音频的应用程序，我希望最大限度地减少延迟。音频按其生成发送，这意味着生成一秒钟的音频需要一秒钟，它不能以比音频速率更快的速度发送。

我最初的想法是发送压缩音频的小数据包，以便客户端可以尽快开始播放。使用 Opus 编解码器，我应该能够发送小至 5 毫秒的音频数据包（最小为 2.5 毫秒），这意味着用户可以很快开始播放，比如说在发送了 2 个这样的数据包之后。

但是，当使用如此小的数据包大小时，会产生很多带宽开销。假设每个 5ms 的音频包是 35 个字节，ip 和 udp 头总共占 28 个字节，这是很多额外的数据。

我的问题是，有没有办法发送具有较大数据包大小但延迟低的实时音频？例如，是否可以在我的应用程序正在生成数据时开始发送数据（部分 udp 数据包），还是必须等待整个数据包的有效负载生成？ （以字节为单位的长度会提前知道）。

如果是这样，我可以使用更大的数据包，但可以更快地开始流式传输数据。

或者网络抖动可能太大以至于我必须缓冲超过 5 毫秒？

Answer 1

您肯定会缓冲超过 5 毫秒。 5ms 是一个极低的缓冲，即使对于播放声卡本身也是如此。只有带有特殊驱动程序（如 ASIO）的声音设备才能达到如此低的水平，并且几乎与它们的低水平一样低。您是否通过您自己的 LAN 发送这些数据包，您可以在其中控制和优先传输？这是真正保证性能的唯一方法。有专门为此构建的第 2 层协议，例如 Ethersound。这取决于您正在构建什么以及您的要求是什么。

网络软件的常见缓冲区大小约为 1400-1500 字节，接近 maximum that you can send per packet over a typical Ethernet network。这是我为您的应用程序推荐的。

Answer 2

我建议您最多使用 534 个字节。如果您想避免碎片化并因此可能导致数据丢失，这就是限制。