The variables "nextChunk" and "crossFadeChunks" are only used when
doCrossFade==1.  This means that we do not have to reset these as long
as doCrossFade!=1.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7265 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The cross-fade check is still very complicated whenever it uses
OutputBuffer internals.  Greatly simplify another check by introducing
outputBufferRelative().

git-svn-id: https://svn.musicpd.org/mpd/trunk@7264 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Another "don't use OutputBuffer internals" patch.  This ignores the
copied "end" value, but I do not think that has ever been a real
issue.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7263 09075e82-0dd4-0310-85a5-a0d7c8717e4f

decoderParent() uses a lot of OutputBuffer internals to see whether
cross-fading should be started.  Move these checks to outputBuffer.c,
which also simplifies decoderParent().

git-svn-id: https://svn.musicpd.org/mpd/trunk@7262 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Declare the variables "test" and "fadePosition" in the scope where
they are really used.  This removes some of the clutter in the
function decodeParent().

git-svn-id: https://svn.musicpd.org/mpd/trunk@7261 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Eliminating some duplicated and.  This also decreases the number of
lines calling processDecodeInput().

git-svn-id: https://svn.musicpd.org/mpd/trunk@7260 09075e82-0dd4-0310-85a5-a0d7c8717e4f

I have spent some time to understand decodeParent(), which does a lot
of obfuscated magic...  I find it useful to help others to also
understand it, so I wrote a few comments.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7259 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Another patch indended to improve the CPP macro hell.  This enlarges
the function decodeParent(), but it cannot be converted into a
standalone function easily, because it references so many local
variables.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7258 09075e82-0dd4-0310-85a5-a0d7c8717e4f

clearOutputBuffer() also resets currentChunk; this might resolve a
theoretical bug.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7257 09075e82-0dd4-0310-85a5-a0d7c8717e4f

dc->start cannot be true after the loop, because it was the loop
condition.  dc->start could have been set by another thread between
the while loop and the if, but I suspect this is not the case the
author intended, so we just remove the dc->start check.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7256 09075e82-0dd4-0310-85a5-a0d7c8717e4f

In my opinion, the code becomes more readable when we explicitly check
"==NOERROR" instead of an implicit 0 check.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7255 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Macros are ugly, and multi-line macros are even more ugly.  This patch
converts processDecodeInput() to a C function.  The disadvantage may
be that the function does not have access to the caller's local
variables, which might be regarded as an advantage on the other hand.
For this reason, we have to pass variable references.  This costs a
tiny bit of performance, but it's worth eliminating this monster
macro, and further patches will optimize this cost down.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7254 09075e82-0dd4-0310-85a5-a0d7c8717e4f

since clearPlayerQueue() is always called within
lockPlaylistInteraction() / unlockPlaylistInteraction(), it simplifies
the code to add another function which calls these three functions.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7253 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Instead of setting quit=1, we can simply break out of the loop.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7252 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The block after "if" breaks out of the loop.  To make the code a
little bit more readable, don't write the rest in an "else" block,
since this code path does not break.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7251 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The method availableOutputBuffer() calculates how many chunks are in
use.  This simplifies code which needs this information, and it can
run without knowing OutputBuffer internals.  The function knows how to
calculate this when begin>end; this might have been a bug in
decodeParent(), which does not.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7250 09075e82-0dd4-0310-85a5-a0d7c8717e4f

After the previous patch, it is clear that the loop in
advanceOutputBufferTo() can be replaced with a simple assignment.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7249 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The parameter "currentChunkSent" is not used and can be dropped.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7248 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This patch removes some clutter from decodeParent() by moving some
code out.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7247 09075e82-0dd4-0310-85a5-a0d7c8717e4f

realloc() has to copy data to the new buffer.  Since convBuffer
contains temporary data only, we can safely use free() plus a new
malloc(), which saves the mempy().

git-svn-id: https://svn.musicpd.org/mpd/trunk@7246 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7245 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Instead of copying URLs everywhere...

[merged r7186 from branches/ew]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7244 09075e82-0dd4-0310-85a5-a0d7c8717e4f

[merged r7185 from branches/ew]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7243 09075e82-0dd4-0310-85a5-a0d7c8717e4f

[merged r7184 from branches/ew]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7242 09075e82-0dd4-0310-85a5-a0d7c8717e4f

It is way more complicated than it should be; and
locking it for thread-safety is too difficult.

[merged r7183 from branches/ew]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7241 09075e82-0dd4-0310-85a5-a0d7c8717e4f

I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once.  So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.

* The shared output buffer variables will still need locking
to guard against race conditions.  So in this effect, we're probably
just as buggy as before.  The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...

* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing

* I haven't tested HTTP streams yet, they should work.

* I've only tested ALSA and Icecast.  ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.

* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)

* The non-blocking (*_nb) variants of the task management functions are
probably overused.  They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.

* It currently segfaults on exit.  I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles.  At least the state file seems to work.  We don't
do any cleanups of the threads on exit, yet.

* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.

* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.

* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:

master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread

At the beginning of every song, the main thread will set
a dirty flag and update the state file.  This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.

* The main thread still wakes up every second on select()
to check for signals; which affects power management.

[merged r7138 from branches/ew]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Clean up some space indentations, replace with tabs.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7239 09075e82-0dd4-0310-85a5-a0d7c8717e4f

git-svn-id: https://svn.musicpd.org/mpd/trunk@7238 09075e82-0dd4-0310-85a5-a0d7c8717e4f

[ew: rewrote commit message as it was confusing]

git-svn-id: https://svn.musicpd.org/mpd/trunk@7237 09075e82-0dd4-0310-85a5-a0d7c8717e4f

autoconf flags for enabling and disabling TCP and unix domain socket
support.  Embedded machines without a TCP stack may be better off
without TCP support.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7236 09075e82-0dd4-0310-85a5-a0d7c8717e4f

This trivial patch addresses bug 1639.  When a bind_to_address
argument starts with a slash, assume that it is the address of a Unix
domain socket.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7235 09075e82-0dd4-0310-85a5-a0d7c8717e4f

It is a good practice to constify pointers when their dereferenced
data is not modified within the functions or its descendants.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7234 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The parameter "port" is not actually used by establishListen(), and
can be removed.  This also allows establishListen() to be used for
socket addresses which have no port.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7233 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The number of buffered chunks can obviously not become negative.  The
"buffered_before_play<0" therefore cannot be useful, so let's remove
it, too.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7232 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The chunk index cannot be negative.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7231 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Do explicit casts before comparing signed with unsigned.  The one in
log.c actually fixes another warning: in the expanded macro, there may
be a check "logLevel>=0", which is always true.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7230 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Unfortunately, the function iconv() wants a non-const input buffer.
In this context, we only have a const pointer, which emits a correct
gcc warning.  Work around this ugliness with an union-deconst hack.
This is optimized away in the binary.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7229 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The counter variables c_samp and c_chan begin at zero and can never be
negative.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7228 09075e82-0dd4-0310-85a5-a0d7c8717e4f

The local variable d_samp is initialized, but never actually used.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7227 09075e82-0dd4-0310-85a5-a0d7c8717e4f

Use unsigned integers in decoderParent() for chunk numbers which
cannot be negative.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7226 09075e82-0dd4-0310-85a5-a0d7c8717e4f