我正在撰写Icecast来源。在处理一首歌时，一切正常。我发送Icecast标题信息，metadeta，然后是文件流。
我的来源需要处理播放列表。目前，在我的应用程序完成为Song A编写流后，它会发送Song B的元数据，然后发送Song B的流。在Song B完成写入Icecast后，我发送了Song C的metadeta和Song C等的文件流。
我当前设置的这个问题是，每次发送下一首歌（metadeta + stream）时，icecast缓冲区都会重置。我假设它可能是每当发送新的metadeta更新时。
如何检测一首歌曲（在Icecast上）何时完成，以便我可以发送新的metadeta（和流）？
编辑：当我使用客户端（例如Icecast）收听VLC信息流时，我注意到它甚至没有播放完整的歌曲，即使已满歌曲正在被Icecast发送和接收。它会跳过歌曲中的部分内容。我想也许Icecast上有一个缓冲区限制，当缓冲区达到这个限制时它会重置？那么我应该故意减慢源将数据发送到Icecast的速度吗？
编辑：我已确定问题是我将音频数据发送到Icecast服务器的速率。目前，我并没有减慢数据传输速度。我需要减慢此传输速度，以便将音频数据写入Icecast的速度与客户端读取流的速度相同/更短。我认为这个比率实际上是bitrate。如果是这种情况，我需要在发送下一个数据块之前让OutputStream线程休眠一段时间。假设这是问题，我能让它睡多久？
答案 0 :(得分：1)
如果您不断将数据刷新到Icecast，则会立即填充缓冲区并循环写入。大多数客户端（尤其是VLC）会在回放期间对其流进行背压，导致TCP窗口大小降至零，这意味着服务器不应再发送任何数据。发生这种情况时，服务器必须等待。一旦窗口大小再次增加，客户端之前流式传输的位置已经从缓冲区中刷出几分钟的音频，从而导致故障（或者通常是断开连接）。
正如您所怀疑的那样，您必须控制将数据发送到Icecast的速率。此速率必须与播放速率相同。虽然这与比特率近似，但它通常并不准确。处理此问题的最佳方法是在发送到编解码器时以编程方式实际播放此音频。无论如何，当使用几个比特率的几个编解码器进行编码时，您将需要尽快完成此任务。