Remove clutter from directory.c.  Everything which saves or loads
to/from the hard disk goes to directory_save.c, and code which sends
directory information to the client is moved into directory_print.c.

Don't pass the raw file descriptor around.  This migration patch is
rather large, because all of the sources have inter dependencies - we
have to change all of them at the same time.

Move everything which dumps a tag to a file descriptor to tag_print.c.
This relaxes dependencies and splits the code into smaller parts.

It should be obvious in which thread or context a function is being
executed at runtime.  The code which was left in decode.c is for the
decoder thread itself; give the file a better name.

This is the last of the three variables.  Now we don't need
playerData.h anymore in most sources.

This releases several include file dependencies.  As a side effect,
"CHUNK_SIZE" isn't defined by decoder_api.h anymore, so we have to
define it directly in the plugins which need it.  It just isn't worth
it to add it to the decoder plugin API.

Now that "dc" is available here, we don't have to pass it to
decoder_is_idle() and decoder_is_starting() anymore.

Include only headers which are really required.  This speeds up
compilation and helps detect cross-layer accesses.

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

We had functions names varied between
outputBufferFoo, fooOutputBuffer, and output_buffer_foo

That was too confusing for my little brain to handle.
And the global variable was somehow named 'cb' instead of
the more obvious 'ob'...

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

All of our main singleton data structures are implicitly shared,
so there's no reason to keep passing them around and around in
the stack and making our internal API harder to deal with.

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

This at least makes the argument list to a lot of our plugin
functions shorter and removes a good amount of line nois^W^Wcode,
hopefully making things easier to read and follow.

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

It actually increases our image size a small bit and may even
hurt performance a very small bit, but makes the code less
verbose and easier to manage.

I don't see a reason for mpd to ever support playing multiple
files at the same time (users can run multiple instances of mpd
if they really want to play Zaireeka, but that's such an edge
case it's not worth ever supporting in our code).

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

Try to only include headers which are really needed.  We should
particularly check all "headers including other headers".  The
long-term goal is to have a manageable, small API for plugins
(decoders, output) without so many mpd internals cluttering the
namespace.

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

Second patch to make OutputBuffer self-contained: since OutputBuffer
now knows its own size, we do not need the global variable
"buffered_chunks" anymore.

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

The chunk size should be in outputBuffer.h since the output buffer
code is its primary user.

git-svn-id: https://svn.musicpd.org/mpd/trunk@7268 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

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

Add -Wmissing-prototypes if compiling with gcc
Static where possible

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

-use tree for tagTracker
-eliminate the master process

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

It just made things more confusing.  We'll just store
the states in playerData_pd->audioDevicesStates and be
done with it (it's a unsigned byte now).

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

Some people have more than 8 devices (the old limit).  It's
pretty easy to support as many as our hardware and OS allows
so we might as well.

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

No point in doing all that extra work for one variable...

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

Indent the entire tree, hopefully we can keep
it indented.

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

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

the GPL header where necessary

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

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

to add the command hooks

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

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

implement in other decoders

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

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

doesn't optimize out order sensitive stuff

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

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

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

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

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

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