| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Tame the large decoder_run_song() function.
|
|
|
|
| |
Let gcc optimize a little bit more.
|
|
|
|
|
| |
No CamelCase. Use bool instead of int. Make both arguments
mandatory.
|
|
|
|
|
|
| |
Same as the previous patch: create up to 16 configured source ports.
The plugin tries to do its best at guessing the right combination for
the given input file, the number of source and destination ports.
|
|
|
|
|
| |
Support up to 16 configured destination ports, that should really be
enough for everybody.
|
|
|
|
| |
Be more clear which kind of port should be configured here.
|
|
|
|
| |
Use the same name as in the libjack API documentation.
|
|
|
|
|
|
|
|
| |
This patch allows the client to load a playlist file from the playlist
directory with a plugin. This can be used with the "load" command,
but the client has to pass the file name including the suffix. We
will probably use the music directory in the future, to support
playlist files inside the music directory.
|
| |
|
|
|
|
| |
Added an interface for loading playlists from a local file.
|
|
|
|
|
| |
This new plugin parses extm3u files. Files without the "#EXTM3U"
header are still parsed by the plain old "m3u" plugin.
|
|
|
|
| |
The caller is responsible for verifying the song URI.
|
|
|
|
|
|
| |
If one plugin has failed to open the playlist, it may have consumed a
part of the stream already. This may lead to a failure in all
following plugins. Fix: rewind the stream before each open() call.
|
|
|
|
|
|
| |
Implement the methods enable() and disable(). Bind the HTTP port in
the enable() method, but reject all incoming connections until the
output is opened.
|
|
|
|
|
| |
When MPD plays a mono song (audio_format.channel==1), connect only one
source port to both destination ports.
|
|
|
|
|
|
| |
After playback has stopped, the ring buffers may still contain
samples. These will be played when playback is started the next
time. We should clear the buffers each time.
|
|
|
|
|
|
|
|
| |
jack_client_new() is deprecated. This requires libjack 0.100
(released nearly 5 years ago). We havn't been testing older libjack
versions anyway.
As a side effect, there is the new option "autostart".
|
| |
|
|
|
|
|
|
| |
Instead of using MPD's audio output name (setting "name"), use a
separate configuration option. Change the default to "Music Player
Daemon".
|
|
|
|
|
|
| |
When a song's tags could not be loaded during database update, log
this as a debug message. Same for a song being removed because its
updated tag could not be read.
|
|
|
|
|
|
| |
Store a list of supported tag items in the database. When loading a
database which does not have a matching list, we must rescan in order
to get the missing information.
|
|
|
|
| |
Convert a string into a tag_type enum.
|
|
|
|
|
| |
Clear the colon. This simplifies all attribute parsers, because they
can now use strcmp() instead of strncmp().
|
|
|
|
| |
If left uninitialized, then the decoder thread quits spuriously.
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Romain Bignon <romain@peerfuse.org>
|
| |
| |
| |
| |
| | |
If no song was queued, then player_control.next_song might contain the
value for the next QUEUE command. We must not reset that.
|
| |
| |
| |
| |
| |
| |
| | |
When the decoder finishes the "queued" song very quickly (before the
"current" song finishes playing), an assertion in do_play() fails
because it thinks that it should start decoding the queued song,
although that has in fact just finished.
|
| |
| |
| |
| |
| | |
The assertion shouldn't access player_control.next_song without
locking it.
|
| |
| |
| |
| | |
Simplify several expressions.
|
| |
| |
| |
| | |
Don't access attributes without the lock.
|
| |
| |
| |
| | |
Don't access decoder_control attributes directly.
|
| |
| |
| |
| | |
Lock the player_control object when modifying its attributes.
|
| | |
|
| |
| |
| |
| |
| | |
Asynchronous decoder startup is gone, and we don't need to check
command==DECODE_COMMAND_START anymore.
|
| |
| |
| |
| | |
These two variables are redundant, we need only one of them.
|
| |
| |
| |
| | |
It's not used if pc.error==PLAYER_ERROR_AUDIO.
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
The START command returns without blocking; we don't need the
asynchronous decoder start anymore.
|
| |
| |
| |
| |
| | |
Return the result to the caller more quickly. This unifies error
handling: no error can be reported before the command is finished.
|
|/
|
|
| |
They are just informational.
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
When the "next" chunk to be played is NULL, return from ao_play()
immediately, without going over the "while" loop (no-op).
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
That variable has been superseded by "remove_notify" (defined in
update_remove.c).
|
|
|
|
|
|
| |
Don't wake up the target thread in every iteration of the wait() loop.
Waking it up once, right after the command has been set, must be
enough.
|
|
|
|
|
|
| |
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.
|