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

Question

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

我最初的想法是发送小包压缩音频，以便客户端可以尽快开始播放。使用Opus编解码器，我应该能够发送小至5ms音频的数据包（最小2.5ms），这意味着用户可以很快开始播放，比如在发送了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个字节。如果你想避免碎片，从而可能导致数据丢失，那就是限制。