libspotify C在音轨末尾发送0

Question

我正在为win32使用libspotify SDK，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回调中。我发现，如果我添加一些节流，并通知主线程它可以醒来进行一些处理，那么轨道末端的额外零将减少到22050帧（或44.1kHz下的500ms）的一次交付

以下是我添加到回调中的一个示例，大量借鉴了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;
}

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

希望这能有所帮助。