流式传输音频时UDP数据包大小/延迟折衷？

我正在构建一个通过udp在线传输实时音频的应用程序，并且希望将延迟降至最低。音频以其生成的形式发送，这意味着需要一秒钟才能生成一秒钟的音频，但发送速度不能超过音频速率。流式传输音频时UDP数据包大小/延迟折衷？

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

但是，使用如此小的数据包大小会带来很多带宽开销。比方说，每个5ms的音频数据包是35个字节，ip和udp数据包总共包含28个字节，这就是很多额外的数据。

我的问题是，有没有办法发送更大的数据包大小的现场音频，但这种低延迟？例如，是否有可能在我的应用程序正在生成数据的过程中开始发送数据（部分udp数据包），还是必须在整个数据包的有效负载生成之前等待？（预先知道字节长度）。

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

或者是网络抖动可能会非常大，我将不得不缓冲超过5ms？

2013-02-04 user1478842

你肯定会缓冲超过5ms。 5ms是非常低的缓冲区，即使是播放声卡本身。只有带有特殊驱动程序的声音设备（如ASIO）才能达到这个最低水平，而且这个设备的使用量和它们一样低。您是否通过自己的局域网发送这些数据包，您可以控制并确定传送的优先顺序？这是真正保证性能的唯一途径。有专门为此构建的第2层协议，如Ethersound。这取决于你正在建设什么，你的要求是什么。

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

来源

2013-02-05 04:52:26 Brad

您引用的答案不是关于最大以太网数据包大小的任何标准或权威来源。 “以太网”一词甚至没有出现在它中。这纯粹是轶事。 – EJP

@EJP，够公平，但你在答案中没有提及任何东西。你能否提供一些关于534字节为什么是幻数的参考？我一直听到1500，并想知道这是否是错误的。 – Brad

这是一个迟到的评论，并且演变已经开始。在任何现代以太网上，“巨型帧”使得以太网限制更可能> 8 kB。（在2013年也可能是这种情况，顺便说一下！）一旦你使用WiFi或互联网或移动电话网络，就会适用不同的数据包/分段大小。 –

我建议你最多使用534字节。如果您希望避免碎片并因此避免可能的数据丢失，那么这就是极限。

来源

2013-02-05 06:23:36 EJP

流式传输音频时UDP数据包大小/延迟折衷？

回答

相关问题