0

In the jukebox.c example of libspotify I count all frames of the current track in the music_delivery callback. When end_of_track is called the frames count is different each time I played the same track. So end_of_track is called several seconds after the song is over. And this timespan differs for each playback.

How can I determine if the song is really over? Do I have to take the duration of the song in seconds and multiply it with the sample rate to take care when the song is over?

Why are more frames delivered than necessary for the track? And why is end_of_track not called on the real end of it? Or I am missing something?

dnlkng
  • 829
  • 1
  • 10
  • 16

1 Answers1

0

end_of_track is called when libspotify has finished delivering audio frames for that track. This is not information about playback - every playback implementation I've seen keeps an internal buffer between libspotify and the sound driver.

Depending on where you're counting, this will account for the difference you're seeing. Since the audio code is outside of libspotify, you need to keep track of what's actually going to the sound driver yourself and stop playback, skip to the next track or whatever you need to do accordingly. end_of_track is basically there to let you know that you can close any output streams you may have from the delivery callback to your audio code or something along those lines.

iKenndac
  • 18,730
  • 3
  • 35
  • 51
  • I count only in the 'music_delivery' callback not in the sound driver implementation. I add up each 'num_frames' parameter to a global variable and print it in 'end_of_track'. I wonder why every time I stream the same track the frame count differs. When the duration of the song is e.g. 3:10 than the total count of samples should be always the same, given that the sample rate is the same. – dnlkng Jan 02 '14 at 20:05
  • Is this causing problems other than your counter changing? There are a number of conditions that could cause the backend to deliver a different version of a track (especially between different users) which are beyond the scope of Stack Overflow. Also, music delivery callbacks are called on a different thread to everything else, so make sure you're not encountering threading bugs when resetting your counter/etc. – iKenndac Jan 02 '14 at 20:16
  • No, I think there are no real problems. I thought I could notify my playback layer when 'end_of_track' was invoked, to update play/pause state. Additionally I thought I could assume that only the complete song is delivered and not more audio data even if it is any silence. – dnlkng Jan 02 '14 at 20:21