MPD used to do that when this code lived in the player thread, but it
was removed by commit 98a7c62d; and
the replacement code in the ALSA output plugin didn't have it.

Without this timer, DispatchSockets() may disable the
MultiSocketMonitor and if Play() doesn't get called soon, it never
gets a chance to generate silence.  However if Play() gets called,
generating silence isn't necessary anymore...

Resulting from this misdesign (added by commit ccafe3f3 in 0.21.3),
the silence generator didn't work reliably.

In DispatchSockets(), when there was not enough data, but enough for
current playback, the method would disable the "active" flag so the
next Play() call would re-enable the MultiSocketMonitor.

This was an abuse of the flag which could result in a crash
in Cancel(), because that method asserts that the period_buffer is
empty, which it may be not.

The solution is to add anther flag called "waiting" which shares some
behavior with the old flag.

Draining isn't finished just because the period_buffer has run empty.
It is only finished after snd_pcm_drain() has succeeded.

Apparently, if snd_pcm_drain() returns EAGAIN, it does not actually
want to be called again; the next call will snd_pcm_drain() will also
return EAGAIN, forever, even though the PCM state has meanwhile
switched to SND_PCM_STATE_SETUP.  This causes a busy loop; to fix
this, we should always check snd_pcm_state() to see if draining is
really required.

See https://github.com/MusicPlayerDaemon/MPD/issues/545

Fix build breakage from commit ea639269

Closes https://github.com/MusicPlayerDaemon/MPD/issues/589

This makes the configuration error more visible, possibly addressing
one part of https://github.com/MusicPlayerDaemon/MPD/issues/589

Commit 1eae9339 added support for
multiple "groups" in the "list" command, and this change allows
clients to detect that this behavior, which had been documented for
several years, is now implemented properly.

Workaround for a regression caused by commit
a06bf388, revealing a problem with
discarding odd numer of frames in the DSD_U32 and DoP converters,
causing distortions with DSD_U32 and DoP on 32 bit CPUs.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/469

This can happen if the DoP converter doesn't get enough source samples
for one destination quad.  This isn't a critical bug, because the OSS
plugin doesn't support DoP yet, but it's good to be prepared.

Instead of passing tag and group, pass an array of tags.  To support a
nested return value, return a nested std::map of std::maps.  Each key
specifies the tag value, and each value may be another nesting level.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/408

Since we now don't duplicate all items, we can easily remove the 64kB
limit from OpusReader::ReadString() and instead silently ignore and
skip all strings which are longer than 4 kB.

This fixes a tag duplication bug with Opus file containing a very long
`METADATA_BLOCK_PICTURE` tag, which occurred because the Opus plugin
returned false after parsing all tags, and then the MPD core fell back
to FFmpeg which scanned the tags again.

Return `404 not found` for some common well-known paths, as clients requesting them usually do that automatically and don't expect endless audio stram.

Closes #572

memcmp use may result in out of bounds access

This reverts commit ff3e2c05.  The
check was necessary, after all, because this is what checked whether
the decoder had finished the current or the next song.

> The "queued" flag can only possibly be set if the decoder is still
> decoding the current song or if the decoder is stopped.

That was wrong because ProcessCommand() sets `queued=true` and also
starts the decoder (if it was idle).

> This is also what the following assert() checks.

That was also wrong, because the assert() has two conditions.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/566

Closes https://github.com/MusicPlayerDaemon/MPD/issues/568

According to http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#sections

Closes https://github.com/MusicPlayerDaemon/MPD/issues/340

If the decoder finishes decoding the current song between the two
IsIdle() checks, MPD stops playback instead of starting the decoder
for the next song.

This is usually not visible problem, because the main thread restarts
it via playlist::ResumePlayback(), but that way it, ignores "single"
mode.

As a workaround, this commit adds another "queued" check which
re-enters the player loop and checks again whether to start the
decoder.

Closes https://github.com/MusicPlayerDaemon/MPD/issues/556

The "queued" flag can only possibly be set if the decoder is still
decoding the current song or if the decoder is stopped.  This is also
what the following assert() checks.  This check was not necessary.