补偿抖动

发布于 2024-11-30 03:42:36 字数 87 浏览 1 评论 0原文

我有一个语音聊天服务,数据包之间的延迟存在变化。我想知道对此的正确反应是什么,以及如何弥补? 例如,我应该以某种方式调整我的音频缓冲区吗?

谢谢

I have a voice-chat service which is experiencing variations in the delay between packets. I was wondering what the proper response to this is, and how to compensate for it?
For example, should I adjust my audio buffers in some way?

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

携君以终年 2024-12-07 03:42:36

您没有说这是您自己开发的应用程序还是您只是在使用的应用程序 - 您显然对前者有更多的控制权,因此这可能很重要。

无论哪种方式,您的网络可能根本不足以支持 VoIP,在这种情况下,您确实需要集中精力改进网络或使用不同的网络。

在用户察觉到问题之前,VoIP 通常需要小于 200 毫秒(毫秒)的端到端延迟。

抖动也很重要 - 简单来说,它是端到端数据包延迟的差异。例如,数据包1和数据包2之间的延迟可以是20ms,但是数据包2和数据包3之间的延迟可以是30ms。抖动缓冲区为 40 毫秒意味着您的应用程序将在数据包之间等待长达 40 毫秒,因此不会“丢失”任何这些数据包。

在抖动缓冲区窗口内未收到的任何数据包通常都会被忽略,因此抖动与连接的有效数据包丢失值之间存在关系。丢包通常也会影响用户对 VoIP 质量的感知 - 不同的代码有不同的容忍度 - 一个共同的目标可能是它应该低于 1%-5%。如果这只是间歇性问题,丢包隐藏技术可以提供帮助。

抖动缓冲区可以是静态的,也可以是动态的(自适应) - 在任何一种情况下,它们越大,它们在呼叫中引入延迟的机会就越大,并且您又回到了上面的延迟问题。典型的抖动缓冲区可能在 20 到 50 毫秒之间,可以静态设置或根据网络条件自动调整。

有关更多信息的良好参考是:
- http://www.voiptroubleshooter.com/indepth/jittersources.html
- http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml

还值得尝试一些常见的互联网连接在线速度测试,因为有很多将进行特定的 VoIP 测试,让您了解您的本地连接是否足以支持 VoIP(尽管请记住,这些测试仅表明网络连接的条件)您运行测试的确切时间)。

You don't say if this is an application you are developing yourself or one which you are simply using - you will obviously have more control over the former so that may be important.

Either way, it may be that your network is simply not good enough to support VoIP, in which case you really need to concentrate on improving the network or using a different one.

VoIP typically requires an end to end delay of less than 200ms (milli seconds) before the users perceive an issue.

Jitter is also important - in simple terms it is the variance in end to end packet delay. For example the delay between packet 1 and packet 2 may be 20ms but the delay between packet 2 and packet 3 may be 30 ms. Having a jitter buffer of 40ms would mean your application would wait up to 40ms between packets so would not 'lose' any of these packets.

Any packet not received within the jitter buffer window is usually ignored and hence there is a relationship between jitter and the effective packet loss value for your connection. Packet loss typically impacts users perception of voip quality also - different codes have different tolerance - a common target might be that it should be lower than 1%-5%. Packet loss concealment techniques can help if it just an intermittent problem.

Jitter buffers will either be static or dynamic (adaptive) - in either case, the bigger they get the greater the chance they will introduce delay into the call and you get back to the delay issue above. A typical jitter buffer might be between 20 and 50ms, either set statically or adapting automatically based on network conditions.

Good references for further information are:
- http://www.voiptroubleshooter.com/indepth/jittersources.html
- http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml

It is also worth trying some of the common internet connection online speed tests available as many will have specific VoIP test that will give you an idea if your local connection is good enough for VoIP (although bear in mind that these tests only indicate the conditions at the exact time you are running your test).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文