| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
We already know if a song is a URL or not based on whether it
has parentDir defined or not. Hopefully one day in the future
we can drop HTTP support from MPD entirely when an HTTP
filesystem comes along and we can access streams via open(2).
|
|
|
|
|
|
| |
The "packed" attribute may have negative side effects on performance.
Remove the "packed" attribute, and increase the size of "song.url" to
a multiple of the machine word size.
|
|
|
|
|
|
| |
Reduce the number of allocations we make, so there's less
pressure on the allocator and less overhead to keep track
of the allocations in.
|
|
|
|
|
| |
It didn't save us any lines of code nor did it do anything
useful since we would overwrite everything anyways.
|
|
|
|
|
| |
There's no reason to scan the playlist for a song we
just allocated.
|
|
|
|
|
|
| |
This got broken when listHandlerFunc was removed. Since we no
longer need it and it's confusing, remove processCommandInternal
and just use process_command.
|
|
|
|
|
|
|
|
|
| |
Instead of allocating a new one, just reuse an existing
one if one is found when rereading the DB. This is a small
makes the previous commit work on subdirectories
of the root music directory.
[1] "song: better handling of existing songs when rereading DB"
|
|
|
|
|
| |
avoid some redundant clearing logic as well, since the tag is
getting freed.
|
|
|
|
|
|
|
|
| |
commands should really not behave differently if they're issued
inside a command list or not; so stop having special handler
functions to deal with them. "update" was the only command
that used this functionality and I changed that in the last
commit to serialize access.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now the "update" command can be issued multiple times regardless
of whether the client is in list mode or not.
We serialize the update tasks to prevent updates from trampling
over each other and will spawn another update task
once the current one is finished updating and reaped.
Right now we cap the queue size to 32 which is probably enough (I
bet most people usually run update with no argument anyways);
but we can make it grow/shrink dynamically if needed. There'll
still be a hard-coded limit to prevent DoS attacks, though.
|
|
|
|
|
| |
It'll be easier to keep track of what code runs in what
task/thread this way.
|
|
|
|
|
| |
Instead of relying on the shortname, just pass the song pointer
to prevent redundant lookups during deletes.
|
|
|
|
|
|
|
| |
Add support for 24 bit PCM samples to all functions. Note that
pcm_convertAudioFormat() converts 24 bit samples to 16 bit; to
preserve full quality, support for "real" 24 bit conversion should be
added.
|
|
|
|
|
|
|
| |
Moved code into separate bit specific functions:
- pcm_volumeChange() -> pcm_volume_change_X()
- pcm_add() -> pcm_add_X()
- pcm_convertTo16bit() -> pcm_convert_8_to_16()
|
|
|
|
|
|
|
|
|
| |
pcm_mix() might overflow the destination buffer if it is smaller than
the second buffer. This is ok because the physical buffer size passed
by cross_fade_apply() is always big enough, but clutters pcm_mix()
with complicated length checks and contains a dangerous buffer
overflow pitfall. Simplify pcm_mix()/pcm_add() and pass only the
smaller buffer size; let cross_fade_apply() do the memcpy().
|
|
|
|
|
|
|
|
|
|
|
|
| |
pause() puts the audio output into pause mode: if supported, it may
perform a special action, which keeps the device open, but does not
play anything. Output plugins like "shout" might want to play silence
during pause, so their clients won't be disconnected. Plugins which
do not support pausing will simply be closed, and have to be reopened
when unpaused.
This pach includes an implementation for the shout plugin, which
sends silence chunks.
|
|
|
|
|
|
| |
The function audio_output_is_pending() returns whether there is a
pending command. This is useful for output plugins as a break
condition for longer loops.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Why have a "_func" prefix on all method names? Also don't typedef the
methods, there is no advantage in that.
|
|
|
|
|
|
| |
Since we use a C99 compiler now, we can assert that the C99 standard
headers are available, no need for complicated compile time checks.
Kill mpd_types.h.
|
|
|
|
|
|
| |
Having an enum type is much nicer than an anonymous integer plus CPP
macros. Note that the old code didn't save any space by declaring the
variable 8 bit, due to padding.
|
|
|
|
|
| |
The union const_hack is only used at one place in the shout plugin.
Remove its global type declaration.
|
|
|
|
|
|
|
| |
C99 will soon have its 10th birthday. Let's not beat the dead C89
horse, and raise the compiler requirements. From now on, we need a
C99 compiler. This adds "-std=gnu99" to the GCC compiler options, in
case GCC is used.
|
|
|
|
|
| |
Do full C99 integer type conversion in all modules which were not
touched by Eric's merged patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seeing the "mpd_" prefix _everywhere_ is mind-numbing as the
mind needs to retrain itself to skip over the first 4 tokens of
a type to get to its meaning. So avoid having extra characters
on my terminal to make it easier to follow code at 2:30 am in
the morning.
Please report any new issues you may come across on Free
toolchains. I realize how difficult it can be to build/maintain
cross-compiling toolchains and I have no intention of forcing
people to upgrade their toolchains to build mpd.
Tested with gcc 2.95.4 and and gcc 4.3.1 on x86-32.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tfing wrote:
> I have quite some files with an empty album tag as they do not come
> from a particular album.
>
> If I want to look for those files and browse them, this happens:
> :: nc localhost 6600
> OK MPD 0.12.0
> find album ""
> ACK [2@0] {find} too few arguments for "find"
>
> I'd like to be able to browse those files in a client like gmpc.
> So these 2 items would have to be developed:
> - list album should report that some files have an empty tag
> - it should be possible to search for an empty tag with the find command
Patch-by: Marc Pavot
ref: http://musicpd.org/mantis/view.php?id=464
|
|
|
|
|
|
|
| |
This only breaks "update" under list command mode and
no other commands. This can be done more optimally
without the extra heap allocation via xstrdup(); but is
uncommon enough to not matter.
|
|
|
|
| |
Improving the signal to noise ratio...
|
|
|
|
|
| |
If a write failed, it's a good sign subsequent writes will fail,
too, so propgate errors all the way up the stack.
|
|
|
|
| |
A long time ago in an mpd far away...
|
|
|
|
|
| |
MPD has supported more audio formats than just MP3
for over five years...
|
|
|
|
| |
We don't change the song pointer there, either.
|
|
|
|
| |
We don't modify the Song when we delete it
|
|
|
|
|
|
| |
It was a huge confusing mess of parameter passing around
and around. Add a few extra assertions to ensure we're
handling parent/child relationships properly.
|
|
|
|
|
|
|
| |
This is like basename(3) but with predictable semantics independent
of C library or build options used. This is also much more strict
and does not account for trailing slashes (mpd should never deal with
trailing slashes on internal functions).
|
|
|
|
|
| |
We no longer fork for directory updates, so we
no longer have children to reap.
|
|
|
|
|
| |
Small memory reduction compared to songvec since most users have
much fewer dirs than songs, but still nice to have.
|
|
|
|
| |
We no longer for for updates
|
|
|
|
|
| |
"free" implies the songvec structure itself is freed,
which is not the case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we updated the mpd metadata database; then there's a chance
some of those songs in the playlist will have updated metadata.
So be on the safe side and increment the playlist version number
if _any_ song changed (this is how all released versions of mpd
did it, too).
This bug was introduced recently when making "update" threaded.
Thanks to stonecrest for the bug report.
|
|
|
|
|
|
|
| |
Make the code more readable by moving the range checks to pcm_range().
gcc does quite a good job at optimizing it: the resulting binary is
exactly the same, although it contains a parametrized shift instead of
hard-coded boundaries.
|
|
|
|
|
| |
Merge some code into an inline function, so we can optimize it later
only once.
|
|
|
|
|
| |
Patch 9a5b5998 broke the "outputenabled" value of the "outputs"
response. Make it print "1" if the output is enabled, "0" otherwise.
|
|
|
|
|
|
| |
* spaces => tabs
* long lines wrapped
* trailing whitespace killed
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There was a known deadlocking bug in the notify library: when the
other thread set notify->pending after the according check in
notify_wait(), the latter thread was deadlocked. Resolve this by
synchronizing all accesses to notify->pending with the notify object's
mutex. Since notify_signal_sync() was never used, we can remove it.
As a consequence, we don't need notify_enter() and notify_leave()
anymore; eliminate them, too.
|
|
|
|
| |
SongList has been superseded by struct songvec.
|
|
|
|
|
|
|
|
| |
During debugging, I found a deadlock between flushAudioBuffer() and
the audio_output_task(): audio_output_task() didn't notice that there
is a command, and flushAudioBuffer() waited forever in notify_wait().
I am not sure yet what is the real cause; work around this for now by
waking up non-finished audio outputs in every iteration.
|