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.
The decoder plugins need this type, so export it in the public API.
This allows is to remove "decode.h" from "decoder_api.h", uncluttering
the API namespace some more.
Unfortunately, we have to pass the DecoderControl pointer to these
inline functions, because the global variable "dc" may not be
available here. This will be fixed later.
The decoder thread is responsible for resetting dc->command after a
command was executed. As a consequence, we can assume that
dc->command is already NONE after decoder_stop().
There is no unlocked caller of clearPlayerQueue(), and the functions
lockPlaylistInteraction() and unlockPlaylistInteraction() are trivial
- merge them.
Since playerPlay() already calls playerStop(), we can remove its
invocation of playerStop() from playPlaylistOrderNumber().
We can also make playerStop a static function.
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.
It was possible for the decoder thread to go into an endless loop
(flac and oggflac decoders): when a "STOP" command arrived, the Read()
callback would return 0, but the EOF() callback returned false. Fix:
when decoder_get_command()!=NONE, return EOF==true.
Storing local configuration in global (static) variables is obviously
a bad idea. Move all those variables into the JackData struct,
including the locks.
There is only one caller of freeJackData() left: jack_finishDriver().
This function is called by the mpd core, and is called exactly once
for every successful jack_initDriver(). We do not need to clear
audioOutput->data, since this variable is invalidated anyway.
Over the lifetime of the jack AudioOutput object, we want a single
valid JackData object, so we can persistently store data there
(configuration etc.). Allocate JackData in jack_initDriver(). After
that, we can safely remove all audioOutput->data==NULL checks (and
replace them with assertions).
No need to destroy the JackData object when an error occurs, since
jack_finishDriver() already frees it. Only deinitialize the jack
library, introduce freeJackClient() for that, and move code from
freeJackData().
Prepare the next patch: make the "!jd" check independent of the
jd->client initialization. This way we can change the "jd"
initialization semantics later.
connect_jack() invokes freeJackData() in every error handler, although
its caller also invokes this function after a failure. We can save a
lot of lines in connect_jack() by removing these redundant
freeJackData() invocations.
When we introduced decoder_read(), we added code which aborts the read
operation when a decoder command arrives. Several plugins however did
not expect that when they were converted to decoder_read(). Add
proper checks to the mp3 and flac decoder plugins.
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.
This flag is used internally; it is set by decoder_seek_where(), and
indicates that the decoder plugin has begun the seek process. It is
used for the case that the decoder plugin has to read data during the
seek process. Before this patch, that was impossible, because
decoder_read() would refuse to read data unless dc->command is NONE.
This patch is kind of a dirty workaround, and needs to be redesigned
later.
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.
If the input stream is not seekable, the try_decode() function
consumes valuable data, which is not available to the decode()
function anymore. This means that the decode() function does not
parse the header correctly. Better skip the detection if we cannot
seek. Or implement better buffering, something like unread() or
buffered rewind().
The return value of audio_linear_dither() is always casted to
mpd_sint16. Returning long does not make sense, and consumed 8 bytes
on a 64 bit platform.
The output buffer is always flushed after being appended to, which
allows us to assume it is always empty. Always start writing at
outputBuffer, don't remember outputPtr.
Fill the whole output buffer at a time by using dither_buffer()'s
ability to decode blocks. Calculate how many samples fit into the
output buffer before each invocation.
Simplifying loops for performance: why check dropSamplesAtEnd in every
iteration, when we could modify the loop boundary? The (writable)
variable samplesLeft can be eliminated; add a write-once variable
pcm_length instead, which is used for the loop condition.
The variable samplesPerFrame is used only in one single closure. Make
it local to this closure. The compiler will probably convert it to a
register anyway.
Preparing for simplifying and thus speeding up the dithering code:
moved dithering to a separate function which contains a trivial loop.
With this patch, only one sample is dithered at a time, but the
following patches will allow us to dither a whole block at a time,
without complicated buffer length checks.
Copy some code from aac_decode() to aac_stream_decode() and apply
necessary changes to allow streaming audio data. Both functions might
be merged later.
initAacBuffer() should really only initialize the buffer; currently,
it also reads data from the input stream and parses the header. All
of the AAC buffer code should probably be moved to a separate library
anyway.
Shifting from the buffer queue is a common operation, and should be
provided as a separate function. Move code to aac_buffer_shift() and
add a bunch of assertions.
When checking for EOF, we should not check whether the read request
has been fully satisified. The InputStream API does not guarantee
that readFromInputStream() always fills the whole buffer, if EOF is
not reached. Since there is the function inputStreamAtEOF() dedicated
for this purpose, we should use it for EOF checking after
readFromInputStream()==0.
Fill the AacBuffer even when nothing has been consumed yet. The
function should not check for consumed data, but for free space at the
end of the buffer.
The flag "ready" indicates whether the input stream is ready and it
has parsed all meta data. Previously, it was impossible for
decodeStart() to see the content type of HTTP input streams, because
at that time, the HTTP response wasn't parsed yet.
With the functions decoder_plugin_register() and
decoder_plugin_unregister(), decoder plugins can register a
"secondary" plugin, like the flac input plugin does this for
"oggflac".
"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.
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.
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.
Since we want to hide mpd internals from the decoder plugins, the
plugins should not check dc->state whether they have already called
decoder_initialized(). Use a local variable to track that.
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.
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.
InputPlugin is the API which is implemented by a decoder plugin. This
belongs to the public API/ABI, so move it to decoder_api.h. It will
later be renamed to something like "decoder_plugin".
Since we have merged dc->stop, dc->seek into one variable, we don't
have to check both conditions at a time; we can replace "!stop &&
!seek" with "none".
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.
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.
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.
After the decoder has been initialized and the audio device has been
opened, don't sleep. The decoder plugin won't do anything special nor
will it care to wake us up for some reason.
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.
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.
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.
Busy wait loops are a bad thing, especially when the response time can
be very long - busy waits eat a lot of CPU, and thus slow down the
other thread. Since the other thread will notify us when it's ready,
we can use notify_wait() instead.
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.
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.
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.
If nothing has been read from the input stream, we don't have to
rewind it.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7397 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The variable "to_read" is never modified except in the last iteration
of the while loop. This means the while condition will never become
false, as the body will break before that may be checked.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7396 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This institutes the usage of a separate thread to buffer HTTP
input. It is basically practice code for using the ringbuffer
code which I plan on reusing for the OutputBuffer as well as
further input buffering for disk (networked filesystems over
WAN, laptops on battery, etc).
Each readFromInputStream() call on an HTTP stream can take
several seconds to complete, short reads are avoided.
A single-threaded solution for systems supporting large enough
SO_RCVBUF values should also be possible and will likely be done
in the future; but this lock-free(except when full/empty)
ringbuffer is cool :)
git-svn-id: https://svn.musicpd.org/mpd/trunk@7393 09075e82-0dd4-0310-85a5-a0d7c8717e4f
We'll be using pipes when waiting for I/O, and condition
variables at other times.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7391 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This will allow both the reader and writer threads to
reset the ringbuffer in a thread-safe fashion.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7390 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This will eliminate unnecessary calls to ringbuf_{read,write}_space
git-svn-id: https://svn.musicpd.org/mpd/trunk@7389 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The auth code also has some ugly usages of string generation
which I will eventually replace with something nicer...
git-svn-id: https://svn.musicpd.org/mpd/trunk@7387 09075e82-0dd4-0310-85a5-a0d7c8717e4f
This piece of code is from the JACK Audio Connection Kit
(trimmed down a bit for better readability).
The vector functions now reuse the common iovec struct used by
writev/readv instead of reinventing an identical but
differently-named struct.
From the comments:
> ISO/POSIX C version of Paul Davis's lock free ringbuffer C++ code.
> This is safe for the case of one read thread and one write thread.
License is LGPL 2.1 or later
git-svn-id: https://svn.musicpd.org/mpd/trunk@7386 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Initialize audioOutput->data with NULL in jack_initDriver().
Previously, this was never initialized, although the other functions
relied on it being NULL prior to jack_openDevice().
This patch addresses bug 0001641[1]. In contrast to the patch provided
by the bug reporter, it moves the initialization before the "!param"
check.
[1] - http://musicpd.org/mantis/view.php?id=1641
git-svn-id: https://svn.musicpd.org/mpd/trunk@7375 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Streaming was broken, beacuse the stream URL was never copied to
path_max_fs.
[ew: replaced strcpy with pathcpy_trunc for ease of auditing]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7371 09075e82-0dd4-0310-85a5-a0d7c8717e4f
During the decoder thread main loop, dc.state must be
DECODE_STATE_STOP. Explicitly assigning it after the "dc.stop" check
is redundant.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7366 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The function wait_main_task() is racy: if the function
wakeup_via_cond() sees the mutex is locked just before
wait_main_task() executes pthread_cond_wait(), the main thread blocks
forever.
Work around this issue by adding a "pending" flag just like in my
notify.c code. A standards-compliant solution should be implemented
later.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7365 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
signal is all we need since we only have one waiter and
likely faster
git-svn-id: https://svn.musicpd.org/mpd/trunk@7349 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
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
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
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
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
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
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
During my tests, it happened that data->position>newPosition. I have
not yet fully understood why this can happen; for now, replace this
with a run-time check.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7334 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The patch "convert blocks until the buffer is full" did not update
data->chunk_length correctly: it added the number of samples, not the
number of bytes. Multiply that with bytes_per_channel
git-svn-id: https://svn.musicpd.org/mpd/trunk@7332 09075e82-0dd4-0310-85a5-a0d7c8717e4f
In the patch "special optimized case for 16bit stereo", the check for
"num_channels==2" was missing.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7331 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Not having to loop for every sample byte (depending on a variable
unknown at compile time) saves a lot of CPU cycles. We could consider
reimplementing this function with liboil...
git-svn-id: https://svn.musicpd.org/mpd/trunk@7330 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Read frame->header.channels once, and pass only this integer to
flac_convert().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7329 09075e82-0dd4-0310-85a5-a0d7c8717e4f
flacWrite() is the only function which sets data->chunk_length. If we
flush the buffer before we return, we can assume that it is always
empty upon entering flacWrite().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7328 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Move the inner loop which converts samples to flac_convert(). There
it is isolated and easier to optimize. This function does not have to
worry about buffer boundaries; the caller (i.e. flacWrite())
calculates how much is left and is responsible for flushing. That
saves a lot of superfluous range checks within the loop.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7327 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Check for flushing the chunk buffer only once per sample, before
iterating over channels and bytes. This saves another 5% CPU cycles.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7326 09075e82-0dd4-0310-85a5-a0d7c8717e4f
AudioFormat.bits is volatile, and to read it, 3 pointers had to be
deferenced. Calculate this value once. This speeds up this function
by 5%.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7325 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
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
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
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
"end" is not being used anymore, since we moved most OutputBuffer
struct accesses into methods.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7314 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
Second patch to make OutputBuffer self-contained: since OutputBuffer
now knows its own size, we do not need the global variable
"buffered_chunks" anymore.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7311 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
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
Buffer sizes should be size_t. This is safe here, at least not
unsafer than without the patch. I have no idea why audioBufferSize
and audioBufferPos were explicitly declared as signed integer.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7296 09075e82-0dd4-0310-85a5-a0d7c8717e4f
When growing the audioOutput->convBuffer, we can use free()+malloc()
instead of realloc(), which saves a memcpy().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7295 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The audio output plugins should get a constant pointer, because they
must not modify the buffer. Since the size is a non-negative buffer
size in bytes, we should change its type to size_t.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7293 09075e82-0dd4-0310-85a5-a0d7c8717e4f
In my previous patch set, I forgot to change the
pcm_sizeOfConvBuffer() invocation in convertAudioFormat() to also use
size_t.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7292 09075e82-0dd4-0310-85a5-a0d7c8717e4f
calculateCrossFadeChunks() still returns int, although the caller uses
it as an unsigned value. Since the function body checks for negative
values, it is safe to cast to unsigned.
crossFade() takes signed parameters, although it callers pass unsigned
integers. Change declaration to unsigned.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7291 09075e82-0dd4-0310-85a5-a0d7c8717e4f
There were some const pointers missing in the previous const-cleanup
patch.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7290 09075e82-0dd4-0310-85a5-a0d7c8717e4f
libfaad wants uint32_t pointers. Passing a long pointer is bugged on
amd64.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7289 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
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
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
This patch rewrites notify.c to use the pthread API, namely
pthread_mutex and pthread_cond. This is a lot cheaper and easier than
the pipe() hack.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7280 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The code paths which return from the functions all have to call
quitDecode(). If we simply break instead of calling quitDecode()
explicitly, this function gets called in the last line of this
function anyway.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7278 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The multi-line expression which calculates sizeToTime is hard to read,
partly because "cb->audioFormat." is too long. Create a separate
inline function in audio.h for that.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7277 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Moved the decision whether to cross-fade the current song to
calculateCrossFadeChunks(). This simplifies the function
decoderParent() and eliminates one layer of indentation.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7276 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Similar to the crossFade() patch: pass chunk objects to playChunk(),
simplify decodeParent() by removing clutter.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7275 09075e82-0dd4-0310-85a5-a0d7c8717e4f
To unify the decoderParent() main loop some more, use it to wait for
the decoder to change the song. Only one single processDecodeInput()
caller left after this patch.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7273 09075e82-0dd4-0310-85a5-a0d7c8717e4f
When there are not enough decode cross-fade chunks in the buffer yet,
the current code does busy-wait, which will delay the decoder even
more. sleep instead, expecting the decoder to wake us up.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7272 09075e82-0dd4-0310-85a5-a0d7c8717e4f
Calling crossFade() with the chunk objects is easier than unrolling
all the chunk properties manually, and decodeParent() can really use
more of these simplifications.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7271 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
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
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
The variable "quit" can be removed, since its only setter can use
"break" instead, just like the other code paths.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7266 09075e82-0dd4-0310-85a5-a0d7c8717e4f
The variables "nextChunk" and "crossFadeChunks" are only used when
doCrossFade==1. This means that we do not have to reset these as long
as doCrossFade!=1.
git-svn-id: https://svn.musicpd.org/mpd/trunk@7265 09075e82-0dd4-0310-85a5-a0d7c8717e4f
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
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
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
Declare the variables "test" and "fadePosition" in the scope where
they are really used. This removes some of the clutter in the
function decodeParent().
git-svn-id: https://svn.musicpd.org/mpd/trunk@7261 09075e82-0dd4-0310-85a5-a0d7c8717e4f
