The protocol mandates that playlist URIs are absolute (i.e. full URI
relative to the music directory, not relative to the parent
directory).  This adds the parameter "directory" to the "playlist"
visitor method.

.. instead of failing playback completely.

Allow gcc to warn when a new format isn't supported.

Let the libsamplerate code initialize itself.

Load the samplerate_converter on MPD startup.  Fail if the converter
name is invalid.

Defaults to "no", which fixes the noise problems.

Defaulting to "with systemd" causes problems for users who install MPD
as an unprivileged user, and it breaks "make distcheck".  It looks
like enabling it by default creates too many practical problems for
unexperienced users.

With --with-systemdsystemunitdir (without a parameter), configure.ac
attempts to auto-detect systemd.

When we have an absolute path that's not inside the music directory,
allow loading it anyway, if we're in "secure" mode (i.e. the client is
connected via UNIX socket).

Conflicts:
	configure.ac
	src/player_control.c
	src/player_thread.c
	src/playlist_song.c

Right now, a playlist with absolute pathnames can only add songs that
are in the same the directory of the playlist or under it.

If uri is an absolute pathname and base_uri is set,
playlist_check_translate_song() will check that base_uri is a prefix
of uri, excluding every other song in the music directory outside
base_uri.

I think in this case base_uri should be completely ignored (and made
NULL) and uri should just be checked against music root directory.

Previously, the condition "defined(play_audio_format)" was used to see
if an output device has been opened, but if the device had failed on
startup, an assertion failure could occur.  This patch adds a separate
flag.

Common function that manages "player" attributes after
audio_output_all_open() has returned.

Now that the player thread can handle SEEK commands while not (yet)
playing, we can remove the "pc.state" check from pc_seek().

This checks both conditions: pending and running.  Fixes yet another
assertion failure!

.. and add a few code comments.

Don't read song.start_ms and song.end_ms, let the player thread manage
this logic instead.

Fixes one more assertion failure.

Fixes possible assertion failure.

Doesn't seem to work yet, getting just noise from a test file.
Seeking isn't implemented yet.

Fixes gcc warnings.

[this is the code from dsd2pcm_src.zip, published on a forum by
Sebastian Gesemann.  Upon request, he has given permission to
redistribute and modify his code, without referring to a specific
license. - mk]

To be used in fixed-size arrays.

Needed for the I/O thread.

The Naim Uniti does not appear to support icecast-style streaming of FLAC
music but does support the codec from a DLNA server. This change looks for
"transferMode.dlna.org: Streaming" in the HTTP request header and responds
with something the Uniti (and hopefully other DLNA clients) accepts.

The only difference in the DLNA streaming mode is the reponse header and
that icecast metadata is disabled. If a client request indicates both modes
are supported, the DLNA mode is preferred (as the Uniti says it supports
both but then rejects a FLAC ICY stream).

Note: This change may be specific to Naim equipment (the only device it was
tested on). E.g. the hardcoding of Content-Length which works but is not a
logically correct value. The change should be backwards-compatible, so
only those clients requesting a DLNA stream will see any difference.

Conflicts:
	src/player_thread.c

When playing a CUE track, the player thread waited for the decoder to
become ready, and then sent a SEEK command to the beginning of the CUE
track.  If that is near the start of the song file, and the track is
short enough, the decoder could have finished decoding already at that
point, and seeking fails.

This commit makes this initial seek more robust: instead of letting
the player thread deal with the difficult timings, let the decoder API
emulate a SEEK command, and return it to the decoder plugin, as soon
as the plugin finishes its initialization.

On Win32, the third setsockopt parameter has type (char *) while on POSIX
systems it is (void *). However, given that it is a no-op cast to go from a
char pointer to a void pointer, we can cast to a char pointer (with a
possible const modifier) on all platforms and satisfy the compiler.
Signed-off-by: Dan McGee <dan@archlinux.org>