From the downloader thread, b_close is always true.

vlc_cancel() is not used, so this was a no-op.

b_error can only become true after the download thread is joined, after
which point it is never evaluated. So we can treat it as always false.

The code size saving in vlc_cleanup_run() is marginal and premature
optimization. In practice, vlc_cleanup_run() makes the source code
harder to follow/read, confuses static analyzers and generates false
positive clobber warnings (on some OSes due to long jumps).

It did exercise some of the cleanup code paths though.

Cancellation cannot occur here.

If the input state were initially "smaller or equal to" PAUSE_S, the
loop would just run forever and deadlock. So assume it is always larger
and remove the slack.

Also fix an invalid function pointer cast.

Close() already clears the array (while destroying it).

Cancellation is not possible there, so this was just a long jump.

See also 63ef5806.

remove audiotrack-audio-channels option.

And reset object if audioTrack_New fails in AudioTrack_Recreate.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Wait for the end of the pacing interval, then wait for the next song
(if it did not start in the mean time).

There are no cancellation points in this function, so there is no point
cleaning up after those.