Preparing for a variant of TimerEvent with coarse 1-second
granularity, but cheaper (with a timer wheel).

Found with cppcoreguidelines-interfaces-global-init
Signed-off-by: Rosen Penev <rosenp@gmail.com>

This allows canceling the blocking method LockWaitWriteAvailable(),
and thus allows breaking free of misbehaving ALSA drivers, avoiding a
MPD lockup.

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

Found with readability-uppercase-literal-suffix
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Signed-off-by: Rosen Penev <rosenp@gmail.com>

Found with readability-uppercase-literal-suffix
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Found with readability-const-return-type
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Found with modernize-use-override
Signed-off-by: Rosen Penev <rosenp@gmail.com>

Pass only the amount of data to PcmExport::Export() when its full
output fits into the ring buffer.  Using only a part of the
PcmExport::Export() result may cause data corruption because
PcmExport's internal state may contain partial blocks which would need
to be rolled back when only some of its output data was used.

As a side effect, this fixes an assertion failure because
PcmExport::CalcInputSize() considered partial block data and could
cause Play() to return a number larger than the "size" parameter.

If snd_pcm_writei() fails, throw an error and stop playback instead
of going into an endless busy loop.

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.

Really drain all data from the period_buffer in any case.

This assertion is not about whether all data has been consumed, but
about whether there has been any data at all.

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.

There cannot be partial frames in the buffer, so we don't need
GetPeriodPosition(); it's enough to check whether head has been moved
in this period.

This gives MPD more control, because attempts to avoid having partial
periods in the ALSA period buffer.  For example, this means that
DrainInternal() doesn't need to generate silence to fill the partial
period.

These options are exclusive.

Returning an empty buffer is a normal result now (since commit
79839db3), and doesn't deserve such a
big comment.