Pass audio_output objects around instead of void pointers. This will
give some more control to the plugin, and prepares for non-blocking
audio outputs.
The output thread could hang indefinitely after finishing CANCEL,
because it could have missed the signal while the output was not
unlocked in ao_command_finished().
This patch removes the wait() call after CANCEL, and adds the flag
"allow_play" instead. While this flag is set, playback is skipped.
With this flag, there will not be any excess wait() call after the
pipe has been cleared.
This patch fixes a bug that causes mpd to discontinue playback after
seeking, due to the race condition described above.
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.
During the whole output thread, the audio_output object is locked, and
it is only unlocked while waiting for the GCond and while running a
plugin method. The error handler in ao_play_chunk() attempted to lock
the object again, which was code from MPD 0.15.x which should have
been removed a long time ago.
Change the assertion on "fail_timer==NULL" in OPEN to a runtime check.
This assertion crashed when the output thread failed while the player
thread was calling audio_output_open().
Replaced all occurrences of g_error() with MPD_ERROR() located in a new header
file 'mpd_error.h'. This macro uses g_critical() to print the error message
and then exits gracefully in contrast to g_error() which would internally call
abort() to produce a core dump.
The macro name is distinctive and allows to find all places with dubious error
handling. The long-term goal is to get rid of MPD_ERROR() altogether. To
facilitate the eventual removal of this macro it was added in a new header
file rather than to an existing header file.
This fixes#2995 and #3007.
Clear the notification before finishing the CANCEL command, so the
notify_wait() after that will always wait for the right notification,
sent by audio_output_all_cancel().
Don't add it to the filter chain, because we need to apply replay gain
before cross-fading with the next song. Add a second replay_gain
filter which is used for the song being faded in (chunk->other).
Add an option for each audio output which enables the use of the
hardware mixer, instead of the software volume code.
This is hardware specific, and assumes linear volume control. This is
not the case for hardware mixers which were tested, making this patch
somewhat useless, but we will use it to experiment with the settings,
to find a good solution.
Apply the replay gain in the output thread. This means a new setting
will be active instantly, without going through the whole music pipe.
And we might have different replay gain settings for each audio output
device.
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.
After CANCEL, call g_cond_wait() only if the new command is still
NONE. Problem is that ao_command_finished() has to unlock the
audio_output object, and in the meantime, the player thread might have
submitted a new 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.
Return false when there was no chunk in the pipe. If the function
returns true, then audio_output_task() will not wait for a notify from
the player thread. This fixes a race condition.
drain() is the opposite of cancel(): it waits until all data in the
buffer has finished playing. Instead of implicitly draining in the
close() method like the ALSA plugin has been doing it forever, let the
output thread decide whether to drain or to cancel.
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.
When the player thread unpauses, it sends CANCEL to the output thread,
after having checked that the output is still open. Problem is when
the output thread closes the device before it can process the CANCEL
command - race condition. This patch adds another "open" check inside
the output thread.
