This is only a slight change to the previous locking behaviour: keep
the decoder unlocked during the loop, and lock it only while checking
decoder_control.command.
Reintroduce a fix from commit 52a0653 (Warren Dukes): "don't call
snd_pcm_drain unless we're already in the RUNNING state". This prevents
ALSA with dmix from sometimes hanging when snd_pcm_drain is called, e.g.
when moving from one song to the next (as in mantis issue 2634).
While paused, the player thread re-locks its mutex and waits for a
signal. This is racy: when the command is set while the thread is
waiting for the lock, it may wait forever. This patch adds another
command check before player_wait().
After CANCEL, the output thread waits for another signal before it
continues playback, to synchronize with the caller. There were some
situations where this signal wasn't sent properly. This patch adds an
explicit g_cond_signal() at two code positions.
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().
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 a single GString buffer object in all functions loading the
database. Enlarge it automatically for long lines. This eliminates
the maximum line length for tag values. There is still an upper limit
of 512 kB to prevent denial of service, but that's reasonable I guess.
Allocate the directory object after the "directory:" line. Assign the
mtime from the input file to this new object, instead of to the parent
directory.
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.
Right after seeking and song change, the elapsed_time shows old
information, because the output thread didn't finish a full chunk
yet. This patch re-adds a second elapsed_time variable, and keeps
track of a fallback value, in case the output thread can't provide a
reliable value.
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.
Don't set the error in play_chunk(); do all the error handling in the
caller. The errored_song attribute isn't set anymore; it doesn't make
sense for PLAYER_ERROR_AUDIO.
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.
Max Kellermann