| Commit message (Collapse) | Author | Files | Lines |
|---|
|
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]
|
|
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.
|
|
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.
|
|
We don't assert on xfade_time > 0 inside any of the xfade
calculations since we have no lock around xfade_time.
|
|
|
|
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.
|
|
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 :<
|
|
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.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Don't be mean with integer sizes. Although we will probably never
have more than 32k buffered chunks, we should use 32 bit integers for
addressing them. We do not save very much (some of the saved space is
eaten by alignment anyway), but we save at least one assembler
instruction for converting short to int.
This change requires some more explicit casts, because gcc was less
picky when comparing short with a full int.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7313 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
First patch without camelCase ;)
output_buffer_skip() lets us eliminate advanceOutputBufferTo(), and
removes yet another external OutputBuffer struct access.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7312 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Try to make OutputBuffer self-contained, without depending on a global
variable.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7310 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7305 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This is the first patch in a series which removes the shared memory,
and moves all the playerData objects into the normal libc heap.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7304 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
The new function successor() can be used to simplify a lot of code
lines and saves a lot of "i+>=buffered_chunks" checks.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7285 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
currentChunk is a global variable, which renders the whole output
buffer code non-reentrant. Although this is not a real problem since
there is only one global output buffer currently, we should move it to
the OutputBuffer struct.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7284 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Hiding OutputBuffer internals, yet again. Two more assertions.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7274 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
sizeof() is the more "natural" or "direct" access to the buffer size,
instead of a macro happening to be used to the buffer declaration.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7270 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
To make access to OutputBuffer easier, move everything which belongs
to a chunk into its own structure, namely OutputBufferChunk.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7269 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Hiding OutputBuffer internals, again. We get an extra assertion in
return.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7267 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
The cross-fade check is still very complicated whenever it uses
OutputBuffer internals. Greatly simplify another check by introducing
outputBufferRelative().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7264 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Another "don't use OutputBuffer internals" patch. This ignores the
copied "end" value, but I do not think that has ever been a real
issue.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7263 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
decoderParent() uses a lot of OutputBuffer internals to see whether
cross-fading should be started. Move these checks to outputBuffer.c,
which also simplifies decoderParent().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7262 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
The method availableOutputBuffer() calculates how many chunks are in
use. This simplifies code which needs this information, and it can
run without knowing OutputBuffer internals. The function knows how to
calculate this when begin>end; this might have been a bug in
decodeParent(), which does not.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7250 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This patch removes some clutter from decodeParent() by moving some
code out.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7247 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
realloc() has to copy data to the new buffer. Since convBuffer
contains temporary data only, we can safely use free() plus a new
malloc(), which saves the mempy().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7246 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
[merged r7185 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7243 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
It is way more complicated than it should be; and
locking it for thread-safety is too difficult.
[merged r7183 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7241 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
The chunk index cannot be negative.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7231 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Do explicit casts before comparing signed with unsigned. The one in
log.c actually fixes another warning: in the expanded macro, there may
be a check "logLevel>=0", which is always true.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7230 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
When the decoder process is faster than the player process, all
decodedd buffers are full at some point in time. The decoder has to
wait for buffers to become free (finished playing). It used to do
this by polling the buffer status 100 times a second.
This generates a lot of unnecessary CPU wakeups. This patch adds a
way for the player process to notify the decoder process that it may
continue its work.
We could use pthread_cond for that, unfortunately inter-process
mutexes/conds are not supported by some kernels (Linux), so we cannot
use this light-weight method until mpd moves to using threads instead
of processes. The other method would be semaphores, which
historically are global resources with a unique name; this historic
API is cumbersome, and I wanted to avoid it.
I came up with a quite naive solution for now: I create an anonymous
pipe with pipe(), and the decoder process reads on that pipe. Until
the player process sends data on it as a signal, the decoder process
blocks.
This can be optimized in a number of ways:
- if the decoder process is still working (instead of waiting for
buffers), we could save the write() system call, since there is
nobody waiting for the notification.
[ew: I tried this using a counter in shared memory, didn't help]
- the pipe buffer will be full at some point, when the decoder thread
is too slow. For this reason, the writer side of the pipe is
non-blocking, and mpd can ignore the resulting EWOULDBLOCK.
- since we have shared memory, we could check whether somebody is
actually waiting without a context switch, and we could just not
write the notification byte.
[ew: tried same method/result as first point above]
- if there is already a notification in the pipe, we could also not
write another one.
[ew: tried same method/result as first/third points above]
- the decoder will only consume 64 bytes at a time. If the pipe
buffer is full, this will result in a lot of read() invocations.
This does not hurt badly, but on a heavily loaded system, this might
add a little bit more load. The preceding optimizations however
are able eliminate the this.
- finally, we should use another method for inter process
notifications - maybe kill() or just make mpd use threads, finally.
In spite of all these possibilities to optimize this code further,
this pipe notification trick is faster than the 100 Hz poll. On my
machine, it reduced the number of wakeups to less than 30%.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7215 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This patch moves code which initializes the OutputBuffer struct to
outputBuffer.c. Although this is generally a good idea, it prepares
the following patch.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7206 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
When dealing with in-memory lengths, the standard type "size_t" should
be used. Missing one can be quite dangerous, because an attacker
could provoke an integer under-/overflow, which may provide an attack
vector.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7205 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
