Question

我使用libspotify SDK，C库为win32。

我认为有正确的设置，每个会话回调都已注册。我不明白为什么我无法收到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搜索轨道并获得结果;在这种情况下，轨道元数据还没有准备好（在播放尝试时）所以我使用了那种＆＃34;轮询＆＃34;在sp_session_load上PostMessage。

任何人都可以帮助我吗？

Answer 1

我遇到了同样的问题，我认为问题在于我过快地消耗数据而没有让其他线程有时间做任何工作，因为我把所有时间花在了music_delivery回调上。我发现如果我添加一些限制并通知主线程它可以唤醒进行一些处理，则轨道末尾的额外零点减少到一个22,050帧（或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;
}

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

希望这有帮助。

libspotify C在轨道末尾发送零

1 个答案: