libmad has a hard-coded maximum PCM buffer size; if we make our
output_buffer just as large, we can avoid the loop, because any
possible size will fit.

These will not be used until they are initialized in SyncAndSend().

Apparently, libmad not only inserts 529 samples of silence at the
beginning of the file, but also removes them at the end.

This solves the last piece of
https://github.com/MusicPlayerDaemon/MPD/issues/601

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

libmad requires padding the input buffer with "MAD_BUFFER_GUARD" zero
bytes at the end of the file, or else it is unable to decode the last
frame.

This fixes yet another bug which prevented this plugin from decoding
the last frame, see
https://github.com/MusicPlayerDaemon/MPD/issues/601

The Xing/LAME frame indicates how many frames there are, but that
excludes the initial Xing/LAME frame.  Therefore, it should not be
counted.

This fixes an off-by-one bug which caused the last frame to be
skipped, fixing one part of
https://github.com/MusicPlayerDaemon/MPD/issues/601

Increment "current_frame" after processing the frame.

This also fixes a bug which caused the bit rate to not update after
seeking.

Broken since commit f8bfea8b

The JACK output plugin would not correctly upmix mono input files when exactly 2 output ports were configured. This fixes that.

The "end of stream" packet is not special; it contains normal data,
and thus we should pass it to OnOggPacket().

This fixes one part of https://github.com/MusicPlayerDaemon/MPD/issues/601

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

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

This exception is usually thrown by class DecoderBridge, but the Opus
plugin (ab)uses it as well, so we need to catch it.

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.