libspotify C 在轨道结束时发送零

Question

我正在使用libspotify SDK，win32 的 C 库。

我认为有一个正确的设置，每个会话回调都被注册。我不明白为什么我不能接到end_of_track 的电话，而music_delivery 继续以零填充22050 长帧被调用。

我尝试开始播放，首先加载带有sp_session_load 的曲目；直到它返回 SP_ERROR_IS_LOADING 我在我的消息队列上发布一条消息（我使用的同步方法，PostMessage win32 API），以便使用相同的 API sp_session_load 再次重新加载。只要它返回SP_ERROR_OK，我就会使用sp_session_play，而music_delivery 会立即以正确的帧开始。

我不知道为什么在跟踪 libspotify 运行时结束时开始发送零填充帧，而不是调用 end_of_track 回调。 在其他条件下，它可以完美运行：我使用了从专辑浏览中获得的sp_track，因此在我加载到当前会话进行播放时，曲目已完全加载：使用此曲目，end_of_track 可以正常工作正确调用。在填充错误的情况下，我使用它的 Spotify URI 搜索轨道并得到结果；在这种情况下，曲目元数据还没有准备好（在播放尝试时），所以我在sp_session_load 和PostMessage 上使用了这种“轮询”。

有人可以帮助我吗？

Answer 1

我遇到了同样的问题，我认为问题在于我消耗数据太快而没有给其他线程时间做任何工作，因为我把所有时间都花在了music_delivery 回调中。我发现，如果我添加一些限制并通知主线程它可以唤醒以进行一些处理，那么轨道末尾的额外零将减少到 22,050 帧（或 44.1kHz 时为 500 毫秒）的一次传递。

这是我添加到回调中的一个示例，大量借鉴了 SDK 提供的 jukebox.c 示例：

/* Buffer 1 second of data, then notify the main thread to do some processing */
if (g_throttle > format->sample_rate) {
    pthread_mutex_lock(&g_notify_mutex);
    g_notify_do = 1;
    pthread_cond_signal(&g_notify_cond);
    pthread_mutex_unlock(&g_notify_mutex);

    // Reset the throttle counter
    g_throttle = 0;
    return 0;
}

正如我所说，在轨道停止之前仍有 22,050 帧零帧，但我相信libspotify 可能故意这样做以确保由接收的帧数 (song_duration_ms = total_frames_delivered / sample_rate * 1000) 计算的持续时间大于或等于sp_track_duration 报告的持续时间。在我的情况下，我尝试流式传输的曲目的持续时间为 172,000ms，没有额外的填充，计算的持续时间为 171,796ms，但使用填充它是 172,296ms。

希望这会有所帮助。