Icecast 流在移动设备上中断后重复

Question

在 Ubuntu 16.04 上运行 Icecast 2.4.4，工作源安装自 Darkice 默认声卡输入。自从在我们下面的相关配置中启用了安装上的介绍后，我们收到了关于在 Android 或 iPhone 等移动设备上中断后流重复的报告：

<limits>
    <clients>3000</clients>
    <sources>10</sources>
    <queue-size>524288</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
    <!-- If enabled, this will provide a burst of data when a client
         first connects, thereby significantly reducing the startup
         time for listeners that do substantial buffering. However,
         it also significantly increases latency between the source
         client and listening client.  For low-latency setups, you
         might want to disable this. -->
    <burst-on-connect>1</burst-on-connect>
    <!-- same as burst-on-connect, but this allows for being more
         specific on how much to burst. Most people won't need to
         change from the default 64k. Applies to all mountpoints  -->
    <burst-size>943718</burst-size>
</limits>
<http-headers>
    <header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<mount>
    <mount-name>/wmnf_high_quality</mount-name>
    <max-listeners>3000</max-listeners>
    <intro>/wmnf_high_quality.mp3</intro>
</mount>

我无法在我的三星 Galaxy s5 上复制该问题，当有来电或短信时，当通话结束或通知结束时，流会从中断处继续。在中断引起的断开/重新连接后，介绍确实会重复，但之后我的流仍然是直播的。报道称流在中断后的最后 5-10 分钟重复播放，他们可以单击暂停/播放按钮在我们的应用中再次接收实时音频。

由于我无法复制，希望这对某些人来说只是电话问题。任何人都可以建议是什么导致流在中断后重复？

我正在等待反馈，看看在移动设备上收听我们的网站播放器时是否会发生这种情况。到目前为止的报告来自我们的 Android/iPhone 应用程序播放器。我没有开发应用程序，所以我不确定播放器。我还要求他们尝试 TuneIn 应用程序中可用的流。同样，我无法复制自己。

Answer 1

我认为这里有两个独立的问题。首先，让我们解决介绍文件。

有很多播放器会在连接失败时自动重新连接。这通常在没有用户干预的情况下发生。连接丢失是移动用户的常见情况。只是在房子里走来走去通过 WiFi 连接，然后移动，然后再回到 WiFi 的情况并不少见。好的播放器会重新连接，音频流中通常不会（或很少）出现故障。但是，添加该介绍文件会产生一个非常严重的感知故障......当这种情况发生时，您的介绍文件会重复播放。因此，强烈建议您不要使用服务器中的介绍文件。如果您希望有一个介绍，您可以在您的网站上播放一个，您可以准确地检测用户是否正在开始新的会话。

第二个问题是您的突发大小非常高。大多数播放器需要缓冲两秒钟的音频数据才能开始播放。播放器还希望在开始播放之前看到一些一致的音频，以确保听众以后不必忍受第二轮缓冲。因此，我通常推荐 5 到 10 秒的突发大小。在您的 128k 情况下，10 秒的缓冲区为 256 KB。您当前的突发大小接近一分钟。这个大缓冲区通常不会以您希望的速度刷新到客户端。原因是播放器应用程序会提供一些背压，导致 TCP 窗口较低，这意味着服务器只能在服务器端缓冲之前推送这么多的缓冲区。

我在您的/wmnf_high_quality 流上使用 Wireshark 进行了一些快速测试：

绘制了两条线...发送的字节数和 TCP 窗口大小。他们大多互相跟随。在连接的最开始，窗口是敞开的，服务器开始将突发缓冲区刷新到客户端。但在 1 秒内，该窗口完全关闭。直到玩家可以在它打开备份之前稍微通过它的初始缓冲区工作。服务器刷新更多的大缓冲区，然后窗口再次关闭。最终我们达到了稳定播放，你可以看到这种尖峰模式出现了。这里发生的情况是播放器端有大量缓冲数据，并且只会接受来自服务器的少量数据。服务器发送它可以发送的所有内容，但窗口大小再次缩小到 ~1 KB。

在此示例中，在稳定播放期间的任何给定时间，我们有一个客户端可能有大约 256 KB - 512 KB 的缓冲数据，而服务器有近 1 MB 的总缓冲区可用，将慢速流勺子馈送到来自此缓冲区中间的客户端。这应该表明突发缓冲区太大，因为客户端无法足够快地消耗它。

现在，可能导致断开连接的复合问题......队列大小。 Icecast 不会在内存中为每个单独的客户端维护单独的缓冲区。它有一个从中读取的缓冲区。 <queue-size> 值设置此缓冲区的大小。如果客户端落后太远，他们的连接将被丢弃。设置更大的queue-size 几乎没有缺点。对于我们所说的大小，服务器上的内存实际上是免费的，因此考虑归结为让用户通过平庸的连接或完全踢掉他们。不过，你的情况有点不同……

通过拥有一个客户端无法使用的大突发大小，您会立即将客户端置于队列大小限制之上，从而迫使它们断开连接。您的听众在反复听到介绍信息时特别意识到这一点，这可能就是他们现在向您报告而以前没有向您报告的原因。

我会推荐以下内容：

• 将burst-size 设置为252144（128 kbit * 8 位/字节 * 1024 字节/千字节 * 10 秒 = 256 KB）
• 将queue-size 设置为burst-size 的4 倍。
• 删除介绍文件。通过您的网站上的代码播放简介，而不是在信息流本身中。