我现在已经尝试了几种方法，用于接收和发送带有Java和C ++的音频流，并且它们工作正常，但延迟开始排队。 我在理解我做错了什么或者我最初需要什么时遇到了一些问题，经过一些阅读后我发现我需要一个抖动缓冲器，因此我只是开始使用一个库，因为它包含了一个jitterbuffer。
它提高了性能，因为它会延迟数据包，因此网络缓冲区等不会像以前那样排队。
所以我想知道，我有什么期望通过UDP进行RTP和设备的专用路由器/网络的延迟？我有大约300-1000ms的延迟，这是一个好的平均值？
0,3-1s的延迟是从一部手机到另一部手机，当从手机流向电脑时我觉得我已经低至0,1-0,3s，这可能与手机是廉价手机有关“低“音频，网络和一般处理能力？
答案 0 :(得分：1)
我可以期待具有RTP over UDP的延迟
衡量数据包在端点之间传输的RTT (round trip time)，这是您可以获得的最佳时间。然后RTT时间存在差异，抖动缓冲区可以处理这种网络延迟。通常在VoIP应用程序中，抖动缓冲区动态地适应从网络排队的数据包的速率。因此，如果您的RTT在50ms-250ms的范围内，并且如果您每RTP个数据包发送40ms的声音，那么您将获得大约200ms的延迟。在测试中我发现200ms并没有那么糟糕。以下是我估计延迟的方法：如果RTT在50到250ms之间，则抖动缓冲器必须适应最坏情况，并假设RTT约为250ms，或单向125ms。然后在发送方面有额外的延迟。如果你每个数据包发送40ms的音频，那么你需要增加40ms的额外延迟，这相当于165ms，此外还有处理，在这种情况下200ms也不会坏。如果你使用Android手机，期望Android手机上的音频播放可能会额外增加200ms的延迟（完全取决于Android版本和手机型号）。是的，这是正确的：当你排队播放声音到os时，你实际上可能只听到200毫秒后的声音！在播放语音时，iPhone的延迟要小得多（我希望在20-40ms的范围内）。 当它增长超过300-400毫秒时，你真的开始注意到语音对话的延迟。 如果您使用WebRTC库，我可能会在voip中获得最佳质量。