Icecast 流在移动设备上中断后重复 [英] Icecast stream repeats after interruptions on mobile devices

问题描述

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

Running Icecast 2.4.4 on Ubuntu 16.04 with a working source mounted from Darkice default audio card input. Since enabling the intro on the mount in our pertinent config below, we have been getting reports of the stream repeating after an interruption on mobile devices such as Android or 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 分钟内重复播放，他们可以点击暂停/播放按钮在我们的应用中再次接收实时音频.

I have not been able to duplicate the issue on my Samsung Galaxy s5, when a call or text comes in, the stream picks up where it left off when done with call or notification ends. The intro does repeat as it should after a disconnect/reconnect caused by the interruption, but my stream is still live afterward. Reports say the stream repeats the last 5-10 minutes after interruptions, they can click on the pause/play button to receive live audio again in our app.

由于我无法复制，希望这只是某些人的电话问题.任何人都可以提出什么原因导致中断后重复播放?

Since I'm not able to duplicate, hoping this is just a phone issue for some people. Would anyone be able to suggest what causes the stream to repeat after interruptions?

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

I'm waiting for feedback to see if this is happening when listening to our website player on a mobile device. The reports so far are from our Android/iPhone app player. I did not develop the app, so I'm not sure of the player. I also asked them to try the stream available in the TuneIn app. Again, I am not able to duplicate myself.

推荐答案

我认为这里有两个独立的问题.首先，让我们处理介绍文件.

I think there are two independent issues here. First, let's address the intro file.

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

There are many players that will automatically reconnect upon connection failure. This often occurs without any intervention from the user. A loss of connection is a common occurrence for mobile users. It's not uncommon when just walking around the house to be connected via WiFi, and then mobile, and then back to WiFi again. Good players will reconnect and there will often be no (or very little) glitch in the audio stream. However, adding that intro file creates a pretty serious perceived glitch... your intro file playing repeatedly as this happens. Therefore, it is strongly recommended that you do not use an intro file from your server. If you wish to have an intro, you can play one on your website where you can accurately detect whether or not the user is starting a new session.

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

The second issue is that you have an extremely high burst size. Most players require two seconds of audio data buffered to begin playback. Players also like to see some consistent audio before they start to playback, to ensure the listener won't have to endure a second round of buffering later on. Therefore, I usually recommend 5 to 10 seconds of burst size. In your case at 128k, 10 seconds of buffer is 256 KB. Your current burst size is nearly a minute long. This large buffer generally does not get flushed to the client as fast as you would like. The reason is that the player application will provide some backpressure which results in a lower TCP window, which means the server is only able to push so much buffer before the server has to buffer on its end.

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

I did some quick testing with Wireshark on your /wmnf_high_quality stream:

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

There are two lines plotted... the bytes sent, and the TCP window size. They mostly follow each other. At the very beginning of the connection, the window is wide open and the server begins flushing that burst buffer to the client. Within 1 second though, that window completely closes. It's not until the player can work through its initial buffer a bit before it opens back up. The server flushes more of that large buffer, and the window closes again. Eventually we hit stable playback, and you can see this spikey pattern emerge. What's happening here is that the player has plenty of buffered data on its end, and will only accept a trickle of data from the server. The server sends everything it can, but again the window size shrinks to ~1 KB.

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

In this example at any given time during stable playback, we have a client which probably has around 256 KB - 512 KB of buffered data, and server with nearly 1 MB of total buffer available, spoon-feeding a slow stream to the client from the middle of this buffer. This should demonstrate that the burst buffer is too large, as it cannot be consumed by the clients fast enough.

现在，可能导致断开连接的复合问题......队列大小.Icecast 不会在内存中为每个单独的客户端维护一个单独的缓冲区.它有一个从中读取的缓冲区. 值设置此缓冲区的大小.如果客户端落后太多，他们的连接将被断开.设置更大的 queue-size 没有什么缺点.对于我们所讨论的大小，服务器上的内存实际上是免费的，因此考虑归结为让用户通过普通连接或完全将其关闭.但是，你的情况有点不同......

Now, the compounding issue which may be causing disconnects.... the queue size. Icecast doesn't maintain a separate buffer in memory for each individual client. It has one buffer which it reads from. The <queue-size> value sets the size of this buffer. If the clients get too far behind, their connection will be dropped. There is little downside to setting a larger queue-size. Memory on the server is effectively free for the sizes we're talking about, so the consideration comes down to letting users slog through a mediocre connection or just kicking them off completely. However, your case is a bit different...

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

By having a large burst size that a client cannot consume, you immediately put the client over the queue size limit, forcing them to be disconnected. Your listeners are particularly aware of this as they hear the intro message repeatedly, which is maybe why they're reporting it to you now and didn't before.

我建议如下:

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

• Set your burst-size to 252144 (128 kbit * 8 bits-per-byte * 1024 bytes-per-kilobyte * 10 seconds = 256 KB)
• Set your queue-size to 4x the burst-size.
• Remove the intro file. Play an intro via code on your website, and not in the stream itself.

这篇关于Icecast 流在移动设备上中断后重复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！