The formula in osx_output_score_sample_rate() to detect multiples of
the source sample rate was broken: when given a 44.1 kHz input file,
it preferred 16 kHz over 48 kHz, because its `frac_portion(16)=0.75`
is smaller than `frac_portion(48)=0.91`.

That formula, introduced by commit 40a1ebee, looks completely
wrong.  It doesn't do what the code comment pretends it does.

Instead of using that `frac_portion` to calculate a score, this patch
adds to the score only if `frac_portion` is nearly `0` or `1`.  This
means that the factor is nearly integer.

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

Fixes `-Wpedantic`.

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

This is the case with uClibc-ng currently.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
(cherry picked from commit 769cd0ee9f0cf8ceb026aa751b5d4a390bb5dbdc)
(changed define to match master)

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

Apparently, Icecast defaults to ISO-8859-1 for MP3:

 http://icecast.org/docs/icecast-2.4.0/config-file.html#mountsettings

This change forces Icecast to UTF-8 without having to configure it in
Icecast's configuration file.

This is the correct thing to do for ports from which a signal ultimately
"originates", such as is the case with mpd.

This header had been available for a long time on Linux, but was
removed in glibc 2.30.  This commit moves the `#include` line inside
the `#ifdef __sun` block and adds a fake declaration of `I_FLUSH` for
the Linux build.

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

Without this, the compiler may optimize accesses away.

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

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.

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.

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