Audio backend flush on mid-track change

[philippe44]

This is trying to address the issue when the user is starting to play a new track using a Spotify UI. Currently, there is no way to differentiate (from an eventing point of view) the LOAD/PLAY that follows a normal end of track from what happens when user just starts another track in the middle of the current one (not talking about prev/next for which there is an event).

The result is that if the audio backend has a fair amount of buffering, it cannot be told to flush it and there is a large lag between the request to play another track and the actual start of the new track.

Candidly, I don't like this PR but I can't find anything better. Ideally, you'd want a special event from Spotify (like what you have on prev/next) that allows the backend's audio buffer/pipe to be flushed.

Still, even what happens on prev/next is not perfect because the cancelCurrentTrack sets ChunkedAudioStream ->isRunning to false but it's asynchronous so even if the backend flushes the pipe when receiving the prev/next event, the old playing song's ChunkedAudioStream continues pushing samples in the pipe. The audio backend has no way to make a proper decision what to do with these samples because the "play/playback_start" event is sent asynchronously to the attempt to stop audio stream, It might restart too early and use samples that should have been discared. I think there should be a way to stop the sample piping and only after it is confirmed to be stopped, then send a play event.

UPDATE: the Win32 PR includes and superseded this

[feelfreelinux]

included in the separate PR