This patch adds a small autoconf M4 library which deals with
auto-detected features. The default for those features is "auto",
which is like the old default: if the library is present on the
system, enable the feature, disable otherwise. If the user explicitly
enables that feature (--enable-alsa), and the library is not present,
configure must fail, because it cannot fulfill the request.
Previous cast to float didn't have any effect because one value is uint
and the other is a floating type but the number itself is even..
This caused some tracks to end before they were really at an end.
The strings passed to tag_pool_get_item() are not null-terminated, and
the caller passes the string length. Don't assume it is
null-terminated anyway by using strcmp().
We're using GLib macros which were introduced in GLib 2.6, like
G_GNUC_MALLOC. Let's just drop support for GLib versions older than
2.6 instead of adding more complicated compatibility hacks.
There are numerous race conditions between the libpulse thread
(pulse_mixer.c callbacks) and the rest of MPD. Protect the volatile
attributes of the pulse_mixer struct with a mutex to fix that.
Don't mess with pulse_mixer.volume for setting the volume. This
variable should only be used to transfer the current volume from
sink_input_vol() to pulse_mixer_get_volume().
The pa_context_get_sink_input_info() function is asynchronous, and
after it returns, libpulse does not guarantee that the operation has
completed yet; in fact, it is not likely. Explicitly wait for the
operation to complete.
The code for the new pulse_wait_for_operation() function was inspired
by mplayer and xine code.
The function mixer_failed() expects the mixer mutex to be already
locked, yet it calls mixer_close(), which attempts to lock the mutex
again, deadlocking itself.
The smartstop feature is a way to tell mpd to stop playing after
current song.
This patche provides:
- 'state' command returns 'smartstop' state (1 or 0)
- 'smartstop' can activate or not the smartstop state
- when song is terminated, mpd stops playing and smartstop is set to 0
This patch fixes a longer delay when moving around songs in the
playlist. The main thread wants to enqueue a new "next" song into the
player thread, but the player thread is waiting inside
audio_output_all_wait() for the output threads. Use
player_control.notify there, so audio_output_all_wait() gets woken up
by the main thread, too.
The functions playPlaylist() and seekSongInPlaylist() expect a song
position, not a song order number. Don't convert the "current"
variable with queue_position_to_order().
The move command now accepts a range for the first argument, in the same
form as other range commands, e.g. move 15:17 3. The first song in the
range is placed at the destination position. Note that as with other
range commands, the range is inclusive on the left only; this example
would move only songs 15 and 16, not 17.
[mk: fixed signed/unsigned warnings; use G_MAXUINT instead of
UINT_MAX]
