流音频时UDP数据包大小/延迟权衡? [英] UDP packet-size/latency tradeoff when streaming audio?

问题描述

我正在构建一个应用程序，该应用程序通过udp在线传输实时音频，并且我希望最大程度地减少延迟.音频是按照其生成的时间发送的，这意味着要花费一秒钟的时间来生成一秒钟的音频，其发送速度不能超过音频速率.

I'm building an application that streams live audio over udp online and I want to minimize latency. The audio is sent as its generated, meaning it takes one second to generate one second of audio, it cannot be sent faster than the audio-rate.

我最初的想法是发送小包压缩音频，以便客户端可以尽快开始播放.使用Opus编解码器，我应该能够发送小至5毫秒的音频数据包(最小2.5毫秒)，这意味着用户可以很快开始播放，可以说已经传送了2个这样的数据包.

My initial idea was to send small packets of compressed audio so the client can begin playback as soon as possible. Using the Opus codec I should be able to send packets as small as 5ms of audio (2.5ms is the minimum), this would mean the user could start playback pretty soon, lets say after 2 such packets have been delivered.

但是，使用这么小的数据包大小会带来很多带宽开销.假设每个5ms音频包为35个字节，ip和udp标头总计28个字节，那就是很多额外的数据.

However there is a lot of bandwidth overhead when using such a small packet size. Lets say each 5ms packet of audio is 35 bytes, the ip and udp headers make up a total of 28 bytes, thats a lot of extra data.

我的问题是，有什么方法可以发送具有较大数据包大小但延迟时间很短的实时音频?例如，是否可以在我的应用程序正在生成数据时开始发送数据(部分udp数据包)，还是必须等到整个数据包的有效载荷产生后才开始发送数据(部分udp数据包)? (以字节为单位的长度会事先知道).

My question is, is there any way to send live audio with larger packet sizes but with this low latency? For example, is it possible to begin sending data (partial udp packets) as my application is in the process of generating it, or must it wait before the entire packet's payload has been produced? (the length in bytes would be known in advance).

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

If so, I could use larger packets but start streaming the data even sooner.

还是网络抖动可能太大，以至于我仍然必须缓冲5ms以上的时间?

Or is network jitter likely to be so large that I would have to buffer much more than 5ms anyway?

推荐答案

您肯定会缓冲5毫秒以上. 5ms是一个非常低的缓冲区，即使对于播放声卡本身也是如此.只有带有特殊驱动程序的声音设备(例如ASIO)才能够将其降到最低，并且降到了最低.您是否正在通过自己的LAN发送这些数据包，以便在其中控制传输并确定其优先级?这是真正保证性能的唯一方法.有专门为此目的构建的第2层协议，例如Ethersound.这取决于您要构建的内容和您的要求.

You will most definitely be buffering more than 5ms. 5ms is an extremely low buffer, even for the playback sound card itself. Only sound devices with special drivers (such as ASIO) are able to get that low, and that is about as low as they go. Are you sending those packets over your own LAN where you can control and prioritize delivery? That is the only way to really guarantee performance. There are layer 2 protocols built specifically for this, such as Ethersound. It depends on what you are building and what your requirements are.

网络软件的常见缓冲区大小约为1400-1500字节，接近您可以通过典型的以太网络.这是我为您的应用程序推荐的.

A common buffer size for network software is around 1400-1500 bytes, which is near the maximum that you can send per packet over a typical Ethernet network. This is what I recommend for your application.

这篇关于流音频时UDP数据包大小/延迟权衡?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！