- 08 Oct, 2008 1 commit
-
-
Max Kellermann authored
"bool" should be used in C99 programs for boolean values.
-
- 29 Sep, 2008 1 commit
-
-
Max Kellermann authored
The old struct initializers are error prone and don't allow moving elements around. Since we are going to overhaul some of the APIs soon, it's easier to have all implementations use C99 initializers.
-
- 07 Sep, 2008 2 commits
-
-
Max Kellermann authored
Get rid of CamelCase, and don't use a typedef, so we can forward-declare it, and unclutter the include dependencies.
-
Max Kellermann authored
The previous patch enabled these warnings. In Eric's branch, they were worked around with a generic deconst_ptr() function. There are several places where we can add "const" to pointers, and in others, libraries want non-const strings. In the latter, convert string literals to "static char[]" variables - this takes the same space, and seems safer than deconsting a string literal.
-
- 29 Aug, 2008 3 commits
-
-
Max Kellermann authored
Since tag_new() uses xmalloc(), it cannot fail - if we're really out of memory, the process will abort.
-
Max Kellermann authored
-
Max Kellermann authored
Getting rid of CamelCase; not having typedefs also allows us to forward-declare the structures.
-
- 26 Aug, 2008 22 commits
-
-
Max Kellermann authored
This releases several include file dependencies. As a side effect, "CHUNK_SIZE" isn't defined by decoder_api.h anymore, so we have to define it directly in the plugins which need it. It just isn't worth it to add it to the decoder plugin API.
-
Max Kellermann authored
The code said "decoder_command==STOP" because that was a conversion from the old "dc->stop" test. As we can now check for all commands in one test, we can simply rewrite that to decoder_command!=NONE.
-
Max Kellermann authored
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).
-
Max Kellermann authored
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().
-
Max Kellermann authored
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.
-
Max Kellermann authored
The "decoder" object reference will be used by another patch.
-
Max Kellermann authored
"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.
-
Max Kellermann authored
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.
-
Max Kellermann authored
dc->seekable is already set by decodeStart().
-
Max Kellermann authored
Provide access to seeking for the decoder plugins; they have to know where to seek, and they need a way to tell us that seeking has failed.
-
Max Kellermann authored
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().
-
Max Kellermann authored
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.
-
Max Kellermann authored
Similar to the previous patch: pass total_time instead of manipulating dc->totalTime directly.
-
Max Kellermann authored
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().
-
Max Kellermann authored
We are now beginning to remove direct structure accesses from the decoder plugins. decoder_clear() and decoder_flush() mask two very common buffer functions.
-
Max Kellermann authored
Moved all of the player-waiting code to decoder_data(), to make OutputBuffer more generic.
-
Max Kellermann authored
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.
-
Max Kellermann authored
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.
-
Max Kellermann authored
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.
-
Max Kellermann authored
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.
-
Max Kellermann authored
Include only headers which are really required. This speeds up compilation and helps detect cross-layer accesses.
-
Max Kellermann authored
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.
-
- 15 Apr, 2008 1 commit
-
-
Max Kellermann authored
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
-
- 13 Apr, 2008 4 commits
-
-
Eric Wong authored
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
-
Eric Wong authored
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
-
Eric Wong authored
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
-
Eric Wong authored
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
-
- 12 Apr, 2008 4 commits
-
-
Max Kellermann authored
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
-
Eric Wong authored
git-svn-id: https://svn.musicpd.org/mpd/trunk@7300 09075e82-0dd4-0310-85a5-a0d7c8717e4f
-
Max Kellermann authored
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
-
Eric Wong authored
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
-
- 26 Mar, 2008 2 commits
-
-
Eric Wong authored
* 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
-
Laszlo Ashin authored
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
-