Busy wait loops are a bad thing, especially when the response time can
be very long - busy waits eat a lot of CPU, and thus slow down the
other thread. Since the other thread will notify us when it's ready,
we can use notify_wait() instead.
Much of the existing code queries all three variables sequentially.
Since only one of them can be set at a time, this can be optimized and
unified by merging all of them into one enum variable. Later, the
"command" checks can be expressed in a "switch" statement.
Since pc->current_song denotes the song which the decoder should use
next, we should move it to DecoderControl. This removes one internal
PlayerControl struct access from the decoder code.
Also add pc.next_song, which is manipulated by the playlist code, and
gets copied to dc.next_song as soon as the decoder is started.
Also enable -Wunused-parameter - this forces us to add the gcc
"unused" attribute to a lot of parameters (mostly library callback
functions), but it's worth it during code refactorizations.
* Correctly define the following CPP directives:
HAVE_FAAD_BUFLEN_FUNCS
HAVE_MP4AUDIOSPECIFICCONFIG
* link against libwavpack correctly in bs
* fix include path for the mpd config.h for mp4ff
git-svn-id: https://svn.musicpd.org/mpd/trunk@7399 09075e82-0dd4-0310-85a5-a0d7c8717e4f
If nothing has been read from the input stream, we don't have to
rewind it.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7397 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The variable "to_read" is never modified except in the last iteration
of the while loop. This means the while condition will never become
false, as the body will break before that may be checked.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7396 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This institutes the usage of a separate thread to buffer HTTP
input. It is basically practice code for using the ringbuffer
code which I plan on reusing for the OutputBuffer as well as
further input buffering for disk (networked filesystems over
WAN, laptops on battery, etc).
Each readFromInputStream() call on an HTTP stream can take
several seconds to complete, short reads are avoided.
A single-threaded solution for systems supporting large enough
SO_RCVBUF values should also be possible and will likely be done
in the future; but this lock-free(except when full/empty)
ringbuffer is cool :)
git-svn-id: https://svn.musicpd.org/mpd/trunk@7393 09075e82-0dd4-0310-85a5-a0d7c8717e4f
We'll be using pipes when waiting for I/O, and condition
variables at other times.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7391 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This will allow both the reader and writer threads to
reset the ringbuffer in a thread-safe fashion.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7390 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This will eliminate unnecessary calls to ringbuf_{read,write}_space
git-svn-id: https://svn.musicpd.org/mpd/trunk@7389 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The auth code also has some ugly usages of string generation
which I will eventually replace with something nicer...
git-svn-id: https://svn.musicpd.org/mpd/trunk@7387 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This piece of code is from the JACK Audio Connection Kit
(trimmed down a bit for better readability).
The vector functions now reuse the common iovec struct used by
writev/readv instead of reinventing an identical but
differently-named struct.
From the comments:
> ISO/POSIX C version of Paul Davis's lock free ringbuffer C++ code.
> This is safe for the case of one read thread and one write thread.
License is LGPL 2.1 or later
git-svn-id: https://svn.musicpd.org/mpd/trunk@7386 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Initialize audioOutput->data with NULL in jack_initDriver().
Previously, this was never initialized, although the other functions
relied on it being NULL prior to jack_openDevice().
This patch addresses bug 0001641[1]. In contrast to the patch provided
by the bug reporter, it moves the initialization before the "!param"
check.
[1] - http://musicpd.org/mantis/view.php?id=1641
git-svn-id: https://svn.musicpd.org/mpd/trunk@7375 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Streaming was broken, beacuse the stream URL was never copied to
path_max_fs.
[ew: replaced strcpy with pathcpy_trunc for ease of auditing]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7371 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Dealing with autotools is too painful when having
to deal with multiple build environments and
configurations.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7368 09075e82-0dd4-0310-85a5-a0d7c8717e4f
During the decoder thread main loop, dc.state must be
DECODE_STATE_STOP. Explicitly assigning it after the "dc.stop" check
is redundant.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7366 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
