aboutsummaryrefslogtreecommitdiffstats
path: root/src/pipe.h (unfollow)
Commit message (Collapse)AuthorFilesLines
2008-11-02music_pipe: add tag pointer to the music_chunk structMax Kellermann1-0/+14
Each music chunk can now carry a tag object. Decoder plugins which support it (e.g. oggvorbis) may use this to inject decoded tags into their output.
2008-11-02music_pipe: document struct music_chunkMax Kellermann1-0/+11
Add doxygen compatible comments.
2008-11-02music_pipe: removed "volatile"Max Kellermann1-2/+2
The "volatile" keyword doesn't help here, because we have proper memory barriers, but it disables some optimizations. Remove it.
2008-11-02music_pipe: renamed "size" to "num_chunks"Max Kellermann1-3/+2
The name "num_chunks" expresses the meaning of the variable better.
2008-11-02music_pipe: no CamelCaseMax Kellermann1-3/+3
Rename all variables and struct members.
2008-11-02music_pipe: renamed "ob" to "music_pipe"Max Kellermann1-6/+6
Last music_pipe rename patch: renamed the global variable (singleton).
2008-11-02music_pipe: more wrapper functionsMax Kellermann1-0/+27
Replace all direct music_pipe struct accesses with wrapper functions. The compiled machine code is the same, but this way, we can change struct internals more easily.
2008-11-02decoder: replaced music_pipe.audioFormat with dc.out_audio_formatMax Kellermann1-4/+4
.. and rename dc.audioFormat to dc.in_audio_format. The music pipe does not need to know the audio format, and its former "audioFormat" property indicated the format of the most recently added chunk, which might be confusing when you are reading the oldest chunks.
2008-11-02music_pipe: renamed ob_* functions to music_pipe_*Max Kellermann1-14/+14
Rename all functions to the new prefix.
2008-11-02music_pipe: renamed struct output_buffer to struct music_pipeMax Kellermann1-6/+7
.. and rename ob_chunk to struct music_chunk.
2008-11-02renamed outputBuffer.[ch] to pipe.[ch]Max Kellermann1-2/+2
No CamelCase in the file name. The output_buffer struct is going to be renamed to music_pipe. There are so many buffer levels in MPD, and calling this one "output buffer" is wrong, because it's not the last buffer before the music reaches the output devices.
2008-10-31added prefix to header macrosMax Kellermann1-2/+2
"LOG_H" is a macro which is also used by ffmpeg/log.h. This is ffmpeg's fault, because short macros should be reserved for applications, but since it's always a good idea to choose prefixed macro names, even for applications, we are going to do that in MPD.
2008-10-12output_buffer: converted ob_is_empty() to inlineMax Kellermann1-1/+4
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/+3
"bool" should be used in C99 programs for boolean values.
2008-10-08notify: removed the "Notify" typedefMax Kellermann1-3/+5
Typedefs shouldn't be used, use the bare struct names instead.
2008-09-29switch to C99 types, part IIMax Kellermann1-4/+3
Do full C99 integer type conversion in all modules which were not touched by Eric's merged patch.
2008-09-07audio_format: converted typedef AudioFormat to struct audio_formatMax Kellermann1-1/+1
Get rid of CamelCase, and don't use a typedef, so we can forward-declare it, and unclutter the include dependencies.
2008-08-26moved global variable "ob" to outputBuffer.hMax Kellermann1-2/+4
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-26eliminate OUTPUT_BUFFER_DC_STOP, OUTPUT_BUFFER_DC_SEEKMax Kellermann1-3/+0
(Ab)use the decoder_command enumeration, which has nearly the same values and the same meaning.
2008-08-26moved convState to struct decoderMax Kellermann1-2/+1
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-26added OutputBuffer.notifyMax Kellermann1-1/+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-11/+8
Moved all of the player-waiting code to decoder_data(), to make OutputBuffer more generic.
2008-08-26clean up CPP includesMax Kellermann1-1/+0
Include only headers which are really required. This speeds up compilation and helps detect cross-layer accesses.
2008-04-15added ob_set_lazy()Max Kellermann1-0/+12
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-14/+14
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-13/+12
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-1/+0
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-12eliminate OutputBuffer.currentChunkMax Kellermann1-2/+0
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-12clean up CPP includesMax Kellermann1-1/+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-12removed "volatile" from OutputBufferChunk propertiesMax Kellermann1-3/+3
There is no danger that gcc will optimize access to OutputBufferChunk properties, since decoder and player work in different chunk objects. It is safe to remove "volatile" here. git-svn-id: https://svn.musicpd.org/mpd/trunk@7318 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12added output_buffer_free()Max Kellermann1-0/+2
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-3/+3
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/+2
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-1/+3
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-12let initOutputBuffer() allocate memoryMax Kellermann1-1/+1
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-12Fix a few more warnings from -WshadowEric Wong1-1/+1
git-svn-id: https://svn.musicpd.org/mpd/trunk@7300 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12moved currentChunk into OutputBufferMax Kellermann1-0/+2
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/+2
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-12added struct OutputBufferChunkMax Kellermann1-6/+10
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-12moved CHUNK_SIZE to outputBuffer.hMax Kellermann1-0/+3
The chunk size should be in outputBuffer.h since the output buffer code is its primary user. git-svn-id: https://svn.musicpd.org/mpd/trunk@7268 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12added outputBufferChunkData()Max Kellermann1-0/+2
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-0/+6
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/+3
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/+6
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/+3
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-12some documentation about OutputBufferMax Kellermann1-0/+9
git-svn-id: https://svn.musicpd.org/mpd/trunk@7245 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12Drop metadata updates from HTTP for now (input HTTP, and shout)Eric Wong1-11/+0
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-2/+0
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-2/+2
The chunk index cannot be negative. git-svn-id: https://svn.musicpd.org/mpd/trunk@7231 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-03-26notify the decoder instead of polling 100hzMax Kellermann1-0/+2
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