我关心的是自适应抖动缓冲器的设计，它随着抖动计算的增加和减少而增加和减少容量。
我认为没有理由对延迟或容量进行任何调整，除非存在缓冲区欠载，然后可能会出现超过容量的传入数据包突发（假设缓冲区容量首先等于缓冲区深度/延迟）。例如，如果我收到 20ms 的数据包，我可能会实现一个 100ms 深的缓冲区，因此可以容纳 5 个数据包。如果数据包之间经过 160 毫秒，那么我可能期望看到多达 8 个数据包几乎同时进入。此时我有两个选择：
- 根据溢出规则丢弃三个数据包
- 不丢弃任何数据包并增加缓冲区容量和延迟
假设选择 2 并且网络状况改善并且数据包传送再次变得正常（抖动值下降）。怎么办？同样，我认为我有两个选择：
- 什么都不做，忍受增加的延迟
- 减少延迟（和容量）
使用自适应缓冲区，我认为我应该做出选择 4，但这似乎不正确，因为它要求我在遇到更大的抖动时人为/任意丢弃在选择 2 时专门保存的音频数据包第一名。
在我看来，正确的做法是最初采取选择#1 来维持延迟，同时丢弃由于抖动增加而延迟交付的数据包（如有必要）。
类似的情况可能是，在 160 毫秒间隙后，我没有得到 8 个数据包的突发，而是只得到 5 个（也许刚刚丢失了 3 个数据包）。在这种情况下，增加缓冲区容量并没有什么好处，但确实有助于减少以后发生溢出的可能性。但如果溢出的想法是要避免的（从网络端），那么我会简单地将缓冲区容量设置为大于配置的“深度/延迟”的固定量。换句话说，如果溢出不是由于本地应用程序未能及时从缓冲区中取出数据包引起的，那么溢出只有两个原因：要么发送方撒谎并且以比约定的更快的速率发送数据包（或从未来发送数据包），或者，
显然，“自适应”缓冲区的全部意义在于识别后一种情况，增加缓冲区容量，并避免丢弃任何数据包。但这给我带来了正确的问题：当网络抖动清除时，我如何“适应”回到理想设置，同时仍然执行相同的“不丢弃数据包”理念？
想法？