The old code called can_seek() with the uninitialized pointer
"isp.is". Has this ever worked? Anyway, initialize "isp" first, then
call can_seek(&isp).
Move everything related to finding and initializing the WVC stream to
wavpack_open_wvc(). This greatly simplifies its error handling and
the function wavpack_streamdecode().
On our way to stabilize the decoder API, we will one day remove the
input stream functions. The most basic function, read() will be
provided by decoder_api.h with this patch. It already contains a loop
(still with manual polling), error/eof handling and decoder command
checks. This kind of code used to be duplicated in all decoder
plugins.
"decoder plugin" is a better name than "input plugin", since the
plugin does not actually do the input - InputStream does. Also don't
use typedef, so we can forward-declare it if required.
The wavpack decoder plugin implements a hack, and it needs the song
URL for that. This API (and the hack) should be revised later, but
add that function for now.
Some decoder commands are implemented in the decoder plugins, thus
they need to have an API call to signal that their current command has
been finished. Let them use the new decoder_command_finished()
instead of the internal dc_command_finished().
Another big patch which hides internal mpd APIs from decoder plugins:
decoder plugins regularly poll dc->command; expose it with a
decoder_api.h function.
dc->audioFormat is set once by the decoder plugins before invoking
decoder_initialized(); hide dc->audioFormat and let the decoder pass
an AudioFormat pointer to decoder_initialized().
We are now beginning to remove direct structure accesses from the
decoder plugins. decoder_clear() and decoder_flush() mask two very
common buffer functions.
decoder_initialized() sets the state to DECODE_STATE_DECODE and wakes
up the player thread. It is called by the decoder plugin after its
internal initialization is finished. More arguments will be added
later to prevent direct accesses to the DecoderControl struct.
The decoder struct should later be made opaque to the decoder plugin,
because maintaining a stable struct ABI is quite difficult. The ABI
should only consist of a small number of stable functions.
dc_command_finished() is invoked by the decoder thread when it has
finished a command (sent by the player thread). It resets dc.command
and wakes up the player thread. This combination was used at a lot of
places, and by introducing this function, the code will be more
readable.
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.
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.
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
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
The patch "Start using song pointers in core data structures" removed
dc->utf8url, and the adaption for wavpack_plugin.c was missing.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7288 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
* malloc() => xmalloc() for error checking
* strncpy() replaced with memcpy(),
memcpy appears perfectly safe here and mpd
does not ever use strncpy() (see r4491)
git-svn-id: https://svn.musicpd.org/mpd/trunk@7211 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This patch does the following:
-enables WVC support for streams as well,
-improves MPD inputStream <=> WavPack stream connector,
-fixes two compile warnings (which were caused by MPD API change).
Mantis #1660 <http://musicpd.org/mantis/view.php?id=1660>
git-svn-id: https://svn.musicpd.org/mpd/trunk@7210 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
DECODE_STATE_STOP is always set as dc->state, and dc->stop
is always cleared. So handle it in decodeStart once rather
than doing it in every plugin.
While we're at it, fix a long-standing (but difficult to
trigger) bug in mpc_decode where we failed to return
if mpc_decoder_initialize() fails.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7122 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Turns out the fix was as simple as specifying the OPEN_TAGS flag when
opening the file. Thanks again to Kodest for figuring this one out.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6657 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This ReplayGain code is currently disabled because WavpackGetTagItem can't
seem to find replaygain_* fields in APEv2 tags (which is how wvgain stores
ReplayGain values). Additionally, because APEv2 tags are stored at the end
of the file, this code is only implemented for regular files and not HTTP
streams. Using HTTP seeking it *may* be possible to implement it for both.
git-svn-id: https://svn.musicpd.org/mpd/trunk@6656 09075e82-0dd4-0310-85a5-a0d7c8717e4f
