| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Anonymous code blocks just to declare variables look ugly. Move the
variable declarations up and disband the code block.
|
|
Similar to previous patch: eliminate one variable by using "break".
This also simplifies the code since we can remove one level of indent.
[ew: rewritten to match current API]
|
|
"break" is so much easier than "eof=1; continue;", when "!eof" is the
loop condition.
|
|
Include only headers which are really required. This speeds up
compilation and helps detect cross-layer accesses.
[ew: minor fixups to not break on new core]
|
|
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.
|
|
Fix a "unused argument" warning, and several warnings regarding void
pointer calculation.
|
|
Using struct iovec means having to cast iov_base everywhere
we want to do pointer arithmetic. Instead, just use rbvec
which can be safely casted to iovec whenever we use
the readv/writev functions.
|
|
Fix a "signed/unsigned comparison warning", and several void pointer
math warnings.
|
|
This avoids writing the metadata of a static song into
the URL of song; leading to confusing looking playlists.
|
|
I considered calling it from metadata_pipe_recv() in
the past, but it's not necessary, so just inline it
again to simplify things.
|
|
unK reported a bug in which explicitly calling "delete"
on each song would cause mpd to lock up. This is actually
triggered when the only song on the mpd playlist is deleted.
Additionally, add an extra assertion to ensure we play
a valid, non-NULL song in play_order_num().
|
|
This way if we previously had a seek error, starting
to play a new song will immediately update the status
metadata.
|
|
Hopefully this fixes a segfault I experienced inside
freeMpdTag earlier with the metadata_pipe. I could
not reproduce the segfault again, however.
Regardless, if multiple threads rely on this, we need to
atomically increment/decrement these counters.
|
|
When we send metadata, there's a remote chance that our pipe is
full and our tag will be silently discarded. If that happens,
the readers will never have a chance to free the tag, so ensure
we free it before returning to the caller.
|
|
I just forgot to reenable/reinitialize it after the core rewrite.
|
|
This has been tested for both playback of streams and
outputting to streams, and seems to work fine with minimal
locking. This reuses the sequence number infrastructure
in OutputBuffer for synchronizing metadata payloads; so
(IMNSHO) should be much more understandable than various
flags being set here and there..
It could still use some cleanup and much testing, but
synchronization issues should be minimal.
|
|
When deleting previous songs, we forgot to update the
playlist.queue value, causing syncPlaylistWithQueue to
trigger a false sync and screw with the playlist.current
pointer; causing the currentsong command to return
an incorrect song.
Thanks to unK to reporting this bug!
|
|
When moving songs around, we forgot to update the
playlist.queue value, causing syncPlaylistWithQueue to
trigger a false sync and screw with the playlist.current
pointer; causing the currentsong command to return
an incorrect song.
|
|
It's possible to calculate an impossibly small value that
we don't have a chance to xfade. Don't die if we can't
find the boundary to start crossfading on
|
|
ob.xfade_time can be changed by the main process without
locking, so copy the float value into a local variable
and recheck the local variable for zero before
continuing.
|
|
We don't assert on xfade_time > 0 inside any of the xfade
calculations since we have no lock around xfade_time.
|
|
It sounds nasty and we didn't do it before the core-rewrite
|
|
|
|
It's redundant, we already track that stuff elsewhere.
|
|
This fixes the case where we wouldn't start playing a newly
added song if we're near the end of the playlist and done
decoding the last song (but still playing from the
buffer).
|
|
buffer_before_play is a prebuffer; always respecting it
is almost as good as having no buffer at all. So we only
respect it when we haven't played anything.
Bugs that were a side effect of this also got fixed:
The player would not stop when we got to the end of the last
song on non-repeating playlists. The playlist would
continuously show the song in the last few seconds of
playback, and never move.
Having crossfade enabled would also amplify the above effect.
So, as a side effect, crossfade now correctly handles
end-of-playlist conditions, as well. It will fade out to
silence when we're at the end of a playlist.
|
|
There are still some places where we try to call this
function without the playlist being stopped. It's really
harmless, to call it and just break out immediately, so
change the assertion.
|
|
data->muteFrame won't necessarily get cleared when it
enters that block of code, so we don't signal the action
as complete until it is actually cleared.
|
|
Hopefully this fixes the skipping problem Qball reports
|
|
ob_wait_sync was a gross hack anyways. We are one
step closer to being able to trigger actions in our
worker threads asynchronously. Just need to make
input (file opening) in decoder happen _after_ our
decoder returns an ACK.
|
|
We spawned the output buffer thread before daemonizing in
initPlayerData(), which is ultra bad because daemonizes forks
and threads are not preserved on exit. Since playerData has
been stripped bare by this core-rewrite anyways, move this code
into the outputBuffer_* group and drop playerData.[ch]
completely
I completely forgot to test this :<
|
|
I'm really no fan of the warning log, it's too complex
for how little it gets used; but fixing it is another
problem.
|
|
This is a huge refactoring of the core mpd process. The
queueing/buffering mechanism is heavily reworked.
The player.c code has been merged into outputBuffer (the actual
ring buffering logic is handled by ringbuf.c); and decode.c
actually handles decoding stuff.
The end result is several hundreds of lines shorter, even though
we still have a lot of DEBUG statements left in there for
tracing and a lot of assertions, too.
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7398 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
|
|
Start using it in the HTTP code
git-svn-id: https://svn.musicpd.org/mpd/trunk@7395 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7394 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
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7392 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
|
|
Makes code easier to read and modularize
git-svn-id: https://svn.musicpd.org/mpd/trunk@7388 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
|
|
vectored I/O will be useful with our ring buffer lib
git-svn-id: https://svn.musicpd.org/mpd/trunk@7385 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
|
|
This patch was taken from
http://bugzilla.livna.org/show_bug.cgi?id=1987 and addresses bug
0001693[1]
[1] - http://musicpd.org/mantis/view.php?id=1693
git-svn-id: https://svn.musicpd.org/mpd/trunk@7374 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7373 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
