1

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

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

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

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

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

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

4

2 回答 2

1

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

网络软件的常见缓冲区大小约为 1400-1500 字节，这接近于您可以通过典型以太网网络发送每个数据包的最大值。这是我为您的应用程序推荐的。

于 2013-02-05T04:52:26.020 回答
0

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

于 2013-02-05T06:23:36.587 回答