Remove the decoder dependency on player_control. All player_control
was needed for is to signal the player thread, and we can do that with
a simple GCond as well.
Allocate a player_control object where needed, and pass it around.
Each "client" object is associated with a "player_control" instance.
This prepares multi-player support.
After we've been hit by Large File Support problems several times in
the past week (which only occur on 32 bit platforms, which I don't
have), this is yet another attempt to fix the issue.
These parameters must be protected with a mutex, too. Wrap everything
inside player_lock()/player_unlock(), and use player_command_locked()
instead of player_command().
Use GMutex/GCond instead of the notify library. Manually lock the
player_control object before accessing the protected attributes. Use
the GCond object to notify the player thread and the main thread.
With these methods, an output plugin can allocate some global
resources only if it is actually enabled. The method enable() is
called after daemonization, which allows for more sophisticated
resource allocation during that method.
Tracking the "elapsed" time from the chunks which we have sent to the
output pipe is very imprecise: since we have implemented the music
pipe, we're sending large number of chunks at once, giving the
"elapsed" time stamp a resolution of usually more than a second.
This patch changes the source of this information to the outputs. If
a chunk has been played by all outputs, the "elapsed" time stamp is
updated.
The new command PLAYER_COMMAND_REFRESH makes the player thread update
its status information: it tells the outputs to update the chunk time
stamp. After that, player_control.elapsed_time is current.
The new player_status struct replaces a bunch of playerGetX()
functions. When we add proper locking to the player_control struct,
we will only need to lock once for the "status" command.
Do all the software volume stuff inside each output thread, not in the
player thread. This allows one software mixer per output device, and
also allows the user to configure the mixer type (hardware or
software) for each audio output.
This moves the global "mixer_type" setting into the "audio_output"
section, deprecating the "mixer_enabled" flag.
The only pc_seek() caller clears the error, rendering the check
useless. Even if the previous PLAY command resulted in a player
error, this check is not very useful.
This updates the copyright header to all be the same, which is
pretty much an update of where to mail request for a copy of the GPL
and the years of the MPD project. This also puts all committers under
'The Music Player Project' umbrella. These entries should go
individually in the AUTHORS file, for consistancy.
Turn the music_pipe into a simple music_chunk queue. The music_chunk
allocation code is moved to music_buffer, and is now managed with a
linked list instead of a ring buffer. Two separate music_pipe objects
are used by the decoder for the "current" and the "next" song, which
greatly simplifies the cross-fading code.
When the playlist is cleared, pc.errored_song is also cleared. This
causes pc_errored_song_uri() to crash, because it assumes that
pc.errored_song is set. Reset pc.error to fix that assumption.
There is only one location using PIPE_EVENT_SIGNAL: to synchronize
player_command() with player_command_finished(). Use the "notify"
library instead of the event_pipe here.
We are going to migrate away from the concept of notifying the main
thread. There should be events sent to it instead. This patch starts
a series to implement that.
It may be desirable to change the range of integer volume levels
(e.g. to 1024, which may utilize shifts instead of expensive integer
divisions). Introduce the constant PCM_VOLUME_1 which describes the
integer value for "100% volume". This is currently 1000.
"idle" waits until something noteworthy happens on the server,
e.g. song change, playlist modified, database updated. This allows
clients to keep up to date without polling.
