aboutsummaryrefslogtreecommitdiffstats
path: root/src/outputBuffer.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2008-10-12output_buffer: converted ob_is_empty() to inlineMax Kellermann1-5/+0
The function ob_is_empty() is called very often. It's worth it to convert it to an inline function.
2008-10-08use the "bool" data type instead of "int"Max Kellermann1-2/+2
"bool" should be used in C99 programs for boolean values.
2008-10-08don't include os_compat.hMax Kellermann1-0/+3
When there are standardized headers, use these instead of the bloated os_compat.h.
2008-10-08notify: removed the "Notify" typedefMax Kellermann1-2/+3
Typedefs shouldn't be used, use the bare struct names instead.
2008-09-29switch to C99 types, part IIMax Kellermann1-2/+2
Do full C99 integer type conversion in all modules which were not touched by Eric's merged patch.
2008-08-26moved global variable "ob" to outputBuffer.hMax Kellermann1-1/+2
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.
2008-08-26moved convState to struct decoderMax Kellermann1-1/+0
Since we moved all PCM conversions to decoder_data(), the attribute convState isn't being used anymore by the OutputBuffer code. Move it to struct decoder.
2008-08-26tail_chunk() returns ob_chunk pointerMax Kellermann1-8/+6
Code simplification: since we are not using in-band signalling with the chunk index anymore, we can just return a pointer to the tail chunk instead of the index.
2008-08-26added OutputBuffer.notifyMax Kellermann1-3/+4
OutputBuffer should be a more generic low-level library, without dependencies to the other headers. This patch adds the field "notify", which is used to signal the player thread. It is passed in the constructor, and removes the need to compile with the decode.h header.
2008-08-26added decoder_data()Max Kellermann1-66/+16
Moved all of the player-waiting code to decoder_data(), to make OutputBuffer more generic.
2008-08-26invoke the notify API directlyMax Kellermann1-2/+3
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.
2008-08-26added dc_command_finished()Max Kellermann1-2/+1
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.
2008-08-26merged start, stop, seek into DecoderControl.commandMax Kellermann1-3/+3
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.
2008-04-15added ob_set_lazy()Max Kellermann1-1/+7
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
2008-04-13Make the OutputBuffer API more consistentEric Wong1-65/+65
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
2008-04-13Stop passing our single OutputBuffer object everywhereEric Wong1-69/+69
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
2008-04-13Stop passing our single DecoderControl object everywhereEric Wong1-15/+13
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
2008-04-12flush after loop in sendDataToOutputBuffer()Max Kellermann1-5/+4
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
2008-04-12yet another migration to size_tMax Kellermann1-4/+4
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
2008-04-12check cb->stop in the while loopMax Kellermann1-4/+4
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
2008-04-12eliminate OutputBuffer.currentChunkMax Kellermann1-29/+51
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
2008-04-12added output_buffer_expand()Max Kellermann1-13/+22
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
2008-04-12initialize all elements in initOutputBuffer()Max Kellermann1-0/+2
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
2008-04-12wake up player on demandMax Kellermann1-1/+9
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
2008-04-12clean up CPP includesMax Kellermann1-5/+0
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
2008-04-12pass DecoderControl object to decoder_sleep()Max Kellermann1-1/+1
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
2008-04-12added output_buffer_free()Max Kellermann1-0/+6
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
2008-04-12don't use short chunk numbersMax Kellermann1-2/+2
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
2008-04-12added output_buffer_skip()Max Kellermann1-0/+6
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
2008-04-12pass buffered_chunks to initOutputBuffer()Max Kellermann1-14/+17
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
2008-04-12fix typo in commentMax Kellermann1-3/+3
git-svn-id: https://svn.musicpd.org/mpd/trunk@7305 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12let initOutputBuffer() allocate memoryMax Kellermann1-2/+2
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
2008-04-12added inline function successor()Max Kellermann1-11/+12
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
2008-04-12moved currentChunk into OutputBufferMax Kellermann1-10/+9
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
2008-04-12added outputBufferShift()Max Kellermann1-0/+10
Hiding OutputBuffer internals, yet again. Two more assertions. git-svn-id: https://svn.musicpd.org/mpd/trunk@7274 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12use sizeof(chunk.data) instead of CHUNK_SIZEMax Kellermann1-2/+2
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
2008-04-12added struct OutputBufferChunkMax Kellermann1-17/+15
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
2008-04-12added outputBufferChunkData()Max Kellermann1-0/+7
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
2008-04-12added outputBufferRelative()Max Kellermann1-4/+9
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
2008-04-12added outputBufferEmpty()Max Kellermann1-0/+5
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
2008-04-12moved check to outputBufferAbsolute()Max Kellermann1-0/+17
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
2008-04-12add method availableOutputBuffer()Max Kellermann1-0/+8
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
2008-04-12moved code to function tailChunk()Max Kellermann1-33/+58
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
2008-04-12use free()+malloc() instead of realloc()Max Kellermann1-1/+3
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
2008-04-12outputBuffer: remove unused variableEric Wong1-1/+0
[merged r7185 from branches/ew] git-svn-id: https://svn.musicpd.org/mpd/trunk@7243 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12Drop metadata updates from HTTP for now (input HTTP, and shout)Eric Wong1-76/+2
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
2008-04-12Initial cut of fork() => pthreads() for decoder and playerEric Wong1-3/+3
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
2008-04-12use unsigned integers in outputBuffer.cMax Kellermann1-1/+1
The chunk index cannot be negative. git-svn-id: https://svn.musicpd.org/mpd/trunk@7231 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12fix sign compare warningsMax Kellermann1-1/+1
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
2008-03-26notify the decoder instead of polling 100hzMax Kellermann1-1/+3
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