| Age | Commit message (Collapse) | Author |
|---|
|
Give player.c a better name, meaning that the code is used to control
the player thread.
|
|
We should avoid having protocol specific code in player.c. Just
return success or failure, and let the caller send the error code to
the MPD client.
|
|
This is the last of the three variables. Now we don't need
playerData.h anymore in most sources.
|
|
Since playerPlay() already calls playerStop(), we can remove its
invocation of playerStop() from playPlaylistOrderNumber().
We can also make playerStop a static function.
|
|
There are no nested queue locks in mpd, thus replace the locked checks
in playerQueueLock(), playerQueueUnlock() with assertions.
|
|
There is no caller of these two functions which locks the player
queue; replace the playerQueueUnlock() call with an assertion.
|
|
All (indirect) callers of queueSong() ensure that the queue state is
BLANK, so there is no need to check it in queueSong() again. As a
side effect, queueSong() cannot fail anymore, and can return void.
Also, playlist_queueError and all its error handling can go away.
|
|
|
|
playerKill() was marked as deprecated, but it seems like a good idea
to do proper cleanup in all threads (e.g. for usable valgrind
results). Introduce the command "EXIT" which makes the player thread
exit cleanly.
|
|
playerWait() stops the player thread (twice!) and closes the output
device. It should be well enough to just send CLOSE_AUDIO, without
STOP.
This requires a tiny change to the player thread code: make it break
when CLOSE_AUDIO is sent.
|
|
Most player*() functions do not actually use the file descriptor, and
always return 0 (success). Eliminate them to get a leaner interface.
|
|
|
|
Move code which runs in the player thread to player_thread.c. Having
a lot of player thread code in decode.c isn't easy to understand.
|
|
The function player_command() inherited the busy-waiting algorithm
from the old code; throw in a wait_main_task() to do idle waiting.
|
|
Don't write CPP when you can express the same in C... macros vs enum
is a good example for that.
|
|
PlayerControl.command replaces the old attributes play, stop, pause,
closeAudio, lockQueue, unlockQueue, seek. The main thread waits for
each command synchronously, so there can only be one command enabled
at a time anyway.
|
|
We want to expose the AudioFormat structure to plugins; remove some
clutter by moving its declaration to a separate header file.
|
|
Don't use wrappers like player_wakeup_decoder_nb(). These have been
wrappers calling notify.c functions, for compatibility with the
existing code when we migrated to notify.c.
|
|
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.
|
|
Include only headers which are really required. This speeds up
compilation and helps detect cross-layer accesses.
|
|
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.
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7367 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
|
|
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@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
|
|
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
|
|
Same as the previous patch: less global variables.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7317 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Now that we do proper locking and signalling instead of continuous
polling for IPC, a deadlock was found: at the end of a song, the
player thread waits until the main thread sets pc->queueState from
PLAYER_QUEUE_DECODE to PLAYER_QUEUE_PLAY. He is never woken up, since
syncPlaylistWithQueue() does not activate the notification. I added
wakeup_player_nb() to setQueueState(), since the player must be
signalled whenever pc->queueState changes.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7303 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7283 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7282 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Instead of copying URLs everywhere...
[merged r7186 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7244 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
|
|
Just one more assertion. There should be more of that!
git-svn-id: https://svn.musicpd.org/mpd/trunk@7204 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
There is unreachable code at several positions, e.g. after an
#if/#end, or after an endless loop. Remove that.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7197 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn-id: https://svn.musicpd.org/mpd/trunk@7143 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This will make refactoring features easier, especially now that
pthreads support and larger refactorings are on the horizon.
Hopefully, this will make porting to other platforms (even
non-UNIX-like ones for masochists) easier, too.
os_compat.h will house all the #includes for system headers
considered to be the "core" of MPD. Headers for optional
features will be left to individual source files.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7130 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7127 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@7126 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
thread-safety work in preparation for rewrite to use pthreads
Expect no regressions against trunk (r7078), possibly minor
performance improvements in update (due to fewer heap
allocations), but increased stack usage.
Applied the following patches:
* maxpath_str for reentrancy (temporary fix, reverted)
* path: start working on thread-safe variants of these methods
* Re-entrancy work on path/character-set conversions
* directory.c: exploreDirectory() use reentrant functions here
* directory/update: more use of reentrant functions + cleanups
* string_toupper: a strdup-less version of strDupToUpper
* get_song_url: a static-variable-free version of getSongUrl()
* Use reentrant/thread-safe get_song_url everywhere
* replace rmp2amp with the reentrant version, rmp2amp_r
* Get rid of the non-reentrant/non-thread-safe rpp2app, too.
* buffer2array: assert strdup() returns a usable value in unit tests
* replace utf8ToFsCharset and fsCharsetToUtf8 with thread-safe variants
* fix storing playlists w/o absolute paths
* parent_path(), a reentrant version of parentPath()
* parentPath => parent_path for reentrancy and thread-safety
* allow "make test" to automatically run embedded unit tests
* remove convStrDup() and maxpath_str()
* use MPD_PATH_MAX everywhere instead of MAXPATHLEN
* path: get rid of appendSlash, pfx_path and just use pfx_dir
* get_song_url: fix the ability to play songs in the top-level music_directory
git-svn-id: https://svn.musicpd.org/mpd/trunk@7106 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
git-svn-id: https://svn.musicpd.org/mpd/trunk@6868 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
The problems I had were related to the OSS driver and USB
device I was using. The problems existed even with the old
busy-waiting scheme enabled.
OSS - Bithead USB => bad
ALSA - Bithead USB => OK
OSS - Onboard i8x0 => OK
ALSA - Onboard i8x0 => OK
bad - slow shutdown, pauses, dropped audio after pause/resume
git-svn-id: https://svn.musicpd.org/mpd/trunk@6861 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
Until we can fix it properly (or replace it with a cleaner event
system), I don't want this in trunk. Currently there are
strange pauses when queueing and during shutdown that I can't
seem to figure out right away.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6860 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
This fixes the problem of playlist moving/changnig while we're paused
Followup to r6822
git-svn-id: https://svn.musicpd.org/mpd/trunk@6859 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
As unfortunate as it is to remove such useful debugging messages, it's
necessary to fix a potential deadlock with signal handling. A bunch of
functions the debug functions call aren't safe to call from a signal
handler. There are some alternate solutions, but they're neither pretty
nor simple. So just remove them entirely for now.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6828 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
as with the stop command, this will cause the player and decoder
to suspend and not wake up hundreds of times a second to poll
a variable for wakeup. This will reduce power consumption
on some CPUs while mpd is paused and not playing.
tests:
pause && unpause => OK
pause && stop && play => OK
pause && exit && restart w/statefile && unpause => OK
pause && block sound device && \
unpause => failed to open sound device \
=> still paused and suspended => unblock sound device &&
unpause => OK (playing)
In all cases, the player process releases the audio device
when paused before going into the suspended state.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6822 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
wait for it to complete an action which it never will.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6488 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
completely stopped. Instead, send them SIGSTOP to pause the process until
they're needed again. Then send them SIGCONT instead of re-spawning them.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6485 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
|
playback is stopped completely. This means the player process will no
longer have to wake up 100 times per second to see if it's been told to
start playing (the main process will just spawn a new player process when
it needs to). On the downside, this means an extra pair of forks() and the
re-initializing of the player and decode processes each time playback is
restarted.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6446 09075e82-0dd4-0310-85a5-a0d7c8717e4f
|
