The function wait_main_task() is racy: if the function
wakeup_via_cond() sees the mutex is locked just before
wait_main_task() executes pthread_cond_wait(), the main thread blocks
forever.
Work around this issue by adding a "pending" flag just like in my
notify.c code. A standards-compliant solution should be implemented
later.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7365 09075e82-0dd4-0310-85a5-a0d7c8717e4f
In lazy mode (previously the default), outputBuffer.c only wakes up
the player when it was previously empty. That caused a deadlock when
the player was waiting for buffered_before_play, since the decoder
wouldn't wake up the player when buffered_before_play was reached. In
non-lazy mode, always wake up the player when a new chunk was decoded.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7364 09075e82-0dd4-0310-85a5-a0d7c8717e4f
When we are in an input plugin, dc.current_song should already be
set. Use it instead of pc.current_song.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7363 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
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
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
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
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
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
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
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
Less global variables: at any invocation of decoder_sleep(), we have a
reference to the DecoderControl anyway, so we should pass it. This
costs less than having to call getPlayerData() in every tiny
function. Maybe some day we will be able to have multiple decoders at
the same time...
git-svn-id: https://svn.musicpd.org/mpd/trunk@7316 09075e82-0dd4-0310-85a5-a0d7c8717e4f
To do proper cleanup before exiting, we have to provide a destructor
for OutputBuffer. One day, valgrind will not complain about memory
leaks!
git-svn-id: https://svn.musicpd.org/mpd/trunk@7315 09075e82-0dd4-0310-85a5-a0d7c8717e4f
