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

We have revision control for a reason :)

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

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

pthread_cond_signal is a no-op if nothing is waiting on it

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

signal is all we need since we only have one waiter and
likely faster

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

Oops, forgot to unlock a mutex

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

The select() in the main event loop blocks now (saving us many
unnecessary wakeups).  This interacted badly with the threads
that were trying to wakeup the main task via
pthread_cond_signal() since the main task was not blocked
on a condition variable, but on select().

So now if we detect a need to wakeup the player, we write
to a pipe which select() is watching instead of blindly
calling pthread_cond_signal().

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

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

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

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

Since tailChunk() automatically flushes full buffers, we do not have
to check this in every iteration of sendDataToOutputBuffer().

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

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

We can also get rid of one the two variables.

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

Checking dc->stop in the while condition and again after the while
loop costs some CPU cycles we should save.

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

OutputBuffer.currentChunk contains redundant data: it is either -1
when there is no chunk which is currently being written, or it equals
"end".  If we always keep chunk[end] in a valid state, we can remove
OutputBuffer.currentChunk.

This patch may look a bit clumsy, especially flushOutputBuffer(), but
that will be fixed later with an major OutputBuffer API overhaul.

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

output_buffer_expand() moves the cb->end to the new position (only its
current successor is allowed) and wakes up the player if is waiting
for the decoder.  This simplifies flushOutputBuffer().

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

The current OutputBuffer object is allocated statically, i.e. it is
zeroed.  To be safe for other cases in the future, also initialize the
other elements.

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

The decoder should not wake up the player when it did not produce a
flushed chunk.  Move the decoder_wakeup_player() call to
flushOutputBuffer() and invoke it only if the buffer was previously
empty.

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

If a unix domain socket already exists, bind() fails.  Unlink the
socket file.

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

During my tests, it happened that data->position>newPosition.  I have
not yet fully understood why this can happen; for now, replace this
with a run-time check.

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

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

The patch "convert blocks until the buffer is full" did not update
data->chunk_length correctly: it added the number of samples, not the
number of bytes.  Multiply that with bytes_per_channel

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

In the patch "special optimized case for 16bit stereo", the check for
"num_channels==2" was missing.

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

Not having to loop for every sample byte (depending on a variable
unknown at compile time) saves a lot of CPU cycles.  We could consider
reimplementing this function with liboil...

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

Read frame->header.channels once, and pass only this integer to
flac_convert().

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

flacWrite() is the only function which sets data->chunk_length.  If we
flush the buffer before we return, we can assume that it is always
empty upon entering flacWrite().

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

Move the inner loop which converts samples to flac_convert().  There
it is isolated and easier to optimize.  This function does not have to
worry about buffer boundaries; the caller (i.e. flacWrite())
calculates how much is left and is responsible for flushing.  That
saves a lot of superfluous range checks within the loop.

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

Check for flushing the chunk buffer only once per sample, before
iterating over channels and bytes.  This saves another 5% CPU cycles.

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

AudioFormat.bits is volatile, and to read it, 3 pointers had to be
deferenced.  Calculate this value once.  This speeds up this function
by 5%.

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

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

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

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

Another global variable cleanup patch.

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

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

There is no danger that gcc will optimize access to OutputBufferChunk
properties, since decoder and player work in different chunk objects.
It is safe to remove "volatile" here.

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