Not supported by libc++.

Required for building with libc++.

bzip2-compressed tarballs are obsolete, xz is better and widely
understood.

Commit 77c63511 caused MPD to become stuck right after a song change.
The problem was that at some point, the MusicBuffer became full, and
the DecoderThread working on the next song waits for the PlayerThread.
However, the PlayerThread was stuck in a loop of g_usleep() calls, and
never bothered to tell the DecoderThread that the MusicBuffer is not
full anymore.  This bug is very old, but its chance to occur went from
nearly 0% to nearly 100%.

The fix is to wake up the DecoderThread before waiting for it.  As a
side effect, I replaced the g_usleep() call with a Cond::Wait() call.

Remove the "do_wait" parameter which is always true.  Check only
command==NONE and merge the "return" statements.

Nothing of interest happens here.  No need to wake up the player.

Allows big-endian users to configure the fallback byte order to
little-endian.  Without this setting, MPD assumes native byte order if
the CD drive can't decide.

Avoid closing it twice.

Fixes a crash bug.  See code comment.

Wake up the OutputThread only if it hasn't already been woken up and
if it isn't already in the playback loop.

After the number of decoded chunks has fallen below the threshold, the
PlayerThread woke up the DecoderThread over and over.  This commit
adds a boolean flag that avoids these duplicate wakeups, and thus
reduces the number of system calls.

Wake up the PlayerThread only if it is really waiting for the decoder.
This greatly reduces the number of system calls in the DecoderThread.

Must hold the Mutex to signal the Cond object safely.

Merge duplicate code.

We have a better solution now.

Add a new CommandResult code called "FINISH" which, unlike "CLOSE",
will attempt to flush the output buffer.  This is a one-shot attempt;
it will do one write, and not try again.

Postpone the write using IdleMonitor instead of scheduling a write
event.  This reduces the number of system calls, because we don't need
to register and unregister the write event in epoll.

.. and rename it to Flush().

For some reason, this got lost in commit 975deca8.

Re-enabling this fixes stuttering at the beginning of radio streams.

Prior to version 0.3, the "length" callback returned a "long" instead
of AFfileoffset.  Now that this API bug fix is a few years old, let's
drop 0.2 support for good.