流式传输音频时UDP数据包大小/延迟权衡？
我正在构建一个通过udp在线传输实时音频的应用程序，我希望最小化延迟。音频以其生成的速度发送，这意味着生成一秒钟的音频需要一秒钟，发送速度不能超过音频速率。
我最初的想法是发送压缩音频的小数据包，以便客户端可以尽快开始播放。使用Opus编解码器，我应该能够发送5毫秒的音频数据包（最低2.5毫秒），这意味着用户可以很快开始播放，比如说在发送了2个这样的数据包之后。
然而，当使用如此小的分组大小时，会有很大的带宽开销。假设每个5ms的音频包是35个字节，ip和udp报头总共有28个字节，这是很多额外的数据。
我的问题是，是否有任何方法可以发送具有较大数据包大小但延迟较低的实时音频？例如，当我的应用程序正在生成数据（部分udp数据包）时，是否可以开始发送数据，还是必须等待整个数据包的有效负载生成？（以字节为单位的长度将提前知道）。
如果是这样，我可以使用更大的数据包，但更快地开始数据流。
或者是网络抖动可能是如此之大，我将不得不缓冲超过5ms无论如何？
共有2个答案
我建议您最多使用534个字节。如果您想避免碎片，从而避免可能的数据丢失，这就是限制。
你肯定会缓冲超过5ms。5ms是一个非常低的缓冲区，即使是播放声卡本身。只有带有特殊驱动程序（如ASIO）的声音设备才能达到如此低的水平，这大约是他们所能达到的最低水平。您是否通过自己的局域网发送这些数据包，在那里您可以控制和优先发送？这是真正保证性能的唯一方法。有专门为此构建的第2层协议，如以太声。这取决于你正在构建什么以及你的要求是什么。
网络软件的常见缓冲区大小约为1400-1500字节，接近通过典型以太网网络发送每个数据包的最大值。这是我为你的申请推荐的。
-
我一直在写一个程序，它使用UDP上的停止和等待协议通过局域网和广域网发送数据包。我最近一直在测试我的程序，并注意到较大的数据包（接近64k字节）的丢包率更高。直觉上这是有道理的，但实际原因是什么？
-
在网上研究了几天后，我来这里寻求帮助。我目前正在为朋友们开发一个简短的2D游戏（实际上只是为了好玩），几天前我了解了剪辑。在这个游戏中，玩家可以收集物体（几乎就像马里奥中的硬币一样）。我的问题是，我在收集硬币时会发出非常短的声音（50kB约1秒），如果玩家在1秒钟内收集3个硬币，那么剪辑会使游戏延迟。如果先例剪辑已经结束，那么就没有延迟。但是如果先例剪辑没有结束，那么尝试再次播放剪辑会使游戏延迟（
-
我正在使用在我的客户端应用程序中执行以及 最大数据包大小限制也存在于中，即？但是我可以使用中的发送大于最大数据包大小的数据块 这是怎么运作的？这是因为是基于流的，负责在较低层创建数据包吗？有什么方法可以增加UDP中的最大数据包大小吗？ 当我在客户端读取时，我从服务器端发送的UDP数据包的一些字节是否可能丢失？如果是，那么有没有办法只检测UDP客户端的损失？
-
我正在开发一个可以流式传输. m3u8播放列表（HLS播放）中的音频流的项目。我正在为上述目的使用Videojs。当我使用. m3u8和（. ts）格式的视频时，一切都很顺利。这些流在所有主要浏览器中播放。代码如下： 和html格式 该代码适用于包含<代码>位的HLS。ts视频流。 现在，我的流提供程序通过给我
-
问题内容： 我在Node.js中使用流服务器来流MP3文件。虽然可以流式传输整个文件，但我不能使用标题将文件流式传输到起始位置并使用终止位置。 我使用like 从秒计算开始和结束字节 在这种情况下，这将为我提供从10秒到下一个第一个数据包的确切字节。 这在Node.js中变得如此简单 现在我有了开始和结束字节，我的媒体服务器将以这种方式从传递给它的自定义值中获取范围 此时，我将获得这个范围， 因此
-
问题内容： 我目前正在尝试将直播麦克风音频从Android设备流式传输到Java程序。我首先在两个Android设备之间发送实时音频，以确认我的方法正确。在接收设备上几乎没有任何延迟地可以完美地听到音频。接下来，我将相同的音频流发送到一个小型Java程序，并验证了数据也已正确发送到此处。现在，我想要做的是对这些数据进行编码，并以某种方式在运行Java程序的服务器上对其进行回放。我宁愿在使用HTML