2004-02-24 00:41:20 +01:00
|
|
|
/* the Music Player Daemon (MPD)
|
2007-04-05 05:22:33 +02:00
|
|
|
* Copyright (C) 2003-2007 by Warren Dukes (warren.dukes@gmail.com)
|
2004-02-24 00:41:20 +01:00
|
|
|
* This project's homepage is: http://www.musicpd.org
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "decode.h"
|
2004-02-27 02:35:23 +01:00
|
|
|
|
2004-02-24 00:41:20 +01:00
|
|
|
#include "player.h"
|
|
|
|
|
#include "playerData.h"
|
|
|
|
|
#include "utils.h"
|
|
|
|
|
#include "pcm_utils.h"
|
|
|
|
|
#include "audio.h"
|
|
|
|
|
#include "path.h"
|
|
|
|
|
#include "log.h"
|
2004-04-11 20:27:12 +02:00
|
|
|
#include "sig_handlers.h"
|
2004-05-18 15:13:55 +02:00
|
|
|
#include "ls.h"
|
2004-06-03 01:22:37 +02:00
|
|
|
#include "utf8.h"
|
2008-01-03 08:29:49 +01:00
|
|
|
#include "os_compat.h"
|
2004-02-24 00:41:20 +01:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
static pthread_cond_t decoder_wakeup_cond = PTHREAD_COND_INITIALIZER;
|
|
|
|
|
static pthread_mutex_t decoder_wakeup_mutex = PTHREAD_MUTEX_INITIALIZER;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
/* called inside decoder_task (inputPlugins) */
|
|
|
|
|
void decoder_wakeup_player(void)
|
2006-07-20 18:02:40 +02:00
|
|
|
{
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_player_nb();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void decoder_sleep(void)
|
|
|
|
|
{
|
|
|
|
|
pthread_cond_wait(&decoder_wakeup_cond, &decoder_wakeup_mutex);
|
|
|
|
|
wakeup_player_nb();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void player_wakeup_decoder_nb(void)
|
|
|
|
|
{
|
|
|
|
|
pthread_cond_signal(&decoder_wakeup_cond);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* called from player_task */
|
|
|
|
|
static void player_wakeup_decoder(void)
|
|
|
|
|
{
|
|
|
|
|
pthread_cond_signal(&decoder_wakeup_cond);
|
|
|
|
|
player_sleep();
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static void stopDecode(DecoderControl * dc)
|
|
|
|
|
{
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
if (dc->start || dc->state != DECODE_STATE_STOP) {
|
2004-02-24 00:41:20 +01:00
|
|
|
dc->stop = 1;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
do { player_wakeup_decoder_nb(); } while (dc->stop);
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static void quitDecode(PlayerControl * pc, DecoderControl * dc)
|
|
|
|
|
{
|
2004-02-24 00:41:20 +01:00
|
|
|
stopDecode(dc);
|
|
|
|
|
pc->state = PLAYER_STATE_STOP;
|
2006-07-14 21:52:29 +02:00
|
|
|
dc->seek = 0;
|
2004-02-24 00:41:20 +01:00
|
|
|
pc->play = 0;
|
|
|
|
|
pc->stop = 0;
|
|
|
|
|
pc->pause = 0;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task();
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static int calculateCrossFadeChunks(PlayerControl * pc, AudioFormat * af)
|
|
|
|
|
{
|
2004-03-05 02:29:08 +01:00
|
|
|
long chunks;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (pc->crossFade <= 0)
|
|
|
|
|
return 0;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
chunks = (af->sampleRate * af->bits * af->channels / 8.0 / CHUNK_SIZE);
|
|
|
|
|
chunks = (chunks * pc->crossFade + 0.5);
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (chunks > (buffered_chunks - buffered_before_play)) {
|
|
|
|
|
chunks = buffered_chunks - buffered_before_play;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (chunks < 0)
|
|
|
|
|
chunks = 0;
|
2004-02-25 18:53:48 +01:00
|
|
|
|
2004-03-05 02:29:08 +01:00
|
|
|
return (int)chunks;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2004-05-19 04:14:20 +02:00
|
|
|
#define handleDecodeStart() \
|
2006-07-14 21:52:29 +02:00
|
|
|
if(decodeWaitedOn) { \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
if(dc->state!=DECODE_STATE_START && \
|
2006-07-14 21:52:29 +02:00
|
|
|
dc->error==DECODE_ERROR_NOERROR) \
|
|
|
|
|
{ \
|
|
|
|
|
decodeWaitedOn = 0; \
|
|
|
|
|
if(openAudioDevice(&(cb->audioFormat))<0) { \
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->erroredUrl, pc->utf8url); \
|
2006-07-14 21:52:29 +02:00
|
|
|
pc->error = PLAYER_ERROR_AUDIO; \
|
2004-11-03 03:11:08 +01:00
|
|
|
ERROR("problems opening audio device while playing \"%s\"\n", pc->utf8url); \
|
2006-07-14 21:52:29 +02:00
|
|
|
quitDecode(pc,dc); \
|
|
|
|
|
return; \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
} else { \
|
|
|
|
|
player_wakeup_decoder(); \
|
|
|
|
|
} \
|
2007-08-12 21:23:48 +02:00
|
|
|
if (pause) { \
|
|
|
|
|
dropBufferedAudio(); \
|
|
|
|
|
closeAudioDevice(); \
|
|
|
|
|
} \
|
2006-07-14 21:52:29 +02:00
|
|
|
pc->totalTime = dc->totalTime; \
|
|
|
|
|
pc->sampleRate = dc->audioFormat.sampleRate; \
|
|
|
|
|
pc->bits = dc->audioFormat.bits; \
|
|
|
|
|
pc->channels = dc->audioFormat.channels; \
|
2004-06-03 14:34:25 +02:00
|
|
|
sizeToTime = 8.0/cb->audioFormat.bits/ \
|
|
|
|
|
cb->audioFormat.channels/ \
|
|
|
|
|
cb->audioFormat.sampleRate; \
|
2004-05-20 05:44:33 +02:00
|
|
|
} \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
else if(dc->state!=DECODE_STATE_START) { \
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->erroredUrl, pc->utf8url); \
|
2004-05-20 05:44:33 +02:00
|
|
|
pc->error = PLAYER_ERROR_FILE; \
|
2004-05-19 04:14:20 +02:00
|
|
|
quitDecode(pc,dc); \
|
|
|
|
|
return; \
|
2004-05-20 05:44:33 +02:00
|
|
|
} \
|
|
|
|
|
else { \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
player_sleep(); \
|
2004-05-20 05:44:33 +02:00
|
|
|
continue; \
|
2006-07-14 21:52:29 +02:00
|
|
|
} \
|
|
|
|
|
}
|
2004-05-19 04:14:20 +02:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static int waitOnDecode(PlayerControl * pc, DecoderControl * dc,
|
|
|
|
|
OutputBuffer * cb, int *decodeWaitedOn)
|
2004-05-19 04:14:20 +02:00
|
|
|
{
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->currentUrl, pc->utf8url);
|
2004-06-01 01:29:35 +02:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
while (dc->start)
|
|
|
|
|
player_wakeup_decoder();
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (dc->start || dc->error != DECODE_ERROR_NOERROR) {
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->erroredUrl, pc->utf8url);
|
2004-02-24 00:41:20 +01:00
|
|
|
pc->error = PLAYER_ERROR_FILE;
|
2006-07-20 18:02:40 +02:00
|
|
|
quitDecode(pc, dc);
|
2004-02-24 00:41:20 +01:00
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-14 21:52:29 +02:00
|
|
|
pc->totalTime = pc->fileTime;
|
|
|
|
|
pc->bitRate = 0;
|
|
|
|
|
pc->sampleRate = 0;
|
|
|
|
|
pc->bits = 0;
|
|
|
|
|
pc->channels = 0;
|
|
|
|
|
*decodeWaitedOn = 1;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static int decodeSeek(PlayerControl * pc, DecoderControl * dc,
|
|
|
|
|
OutputBuffer * cb, int *decodeWaitedOn, int *next)
|
2004-05-19 04:14:20 +02:00
|
|
|
{
|
2006-07-14 21:52:29 +02:00
|
|
|
int ret = -1;
|
2004-05-19 04:14:20 +02:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
if (dc->state == DECODE_STATE_STOP || dc->error ||
|
|
|
|
|
strcmp(dc->utf8url, pc->utf8url) != 0) {
|
|
|
|
|
stopDecode(dc);
|
|
|
|
|
*next = -1;
|
|
|
|
|
cb->begin = 0;
|
|
|
|
|
cb->end = 0;
|
|
|
|
|
dc->error = 0;
|
|
|
|
|
dc->start = 1;
|
|
|
|
|
waitOnDecode(pc, dc, cb, decodeWaitedOn);
|
|
|
|
|
}
|
|
|
|
|
if (dc->state != DECODE_STATE_STOP && dc->seekable) {
|
|
|
|
|
*next = -1;
|
|
|
|
|
dc->seekWhere = pc->seekWhere > pc->totalTime - 0.1 ?
|
|
|
|
|
pc->totalTime - 0.1 : pc->seekWhere;
|
|
|
|
|
dc->seekWhere = 0 > dc->seekWhere ? 0 : dc->seekWhere;
|
|
|
|
|
dc->seekError = 0;
|
|
|
|
|
dc->seek = 1;
|
|
|
|
|
do { player_wakeup_decoder(); } while (dc->seek);
|
|
|
|
|
if (!dc->seekError) {
|
|
|
|
|
pc->elapsedTime = dc->seekWhere;
|
|
|
|
|
ret = 0;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
pc->seek = 0;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task();
|
2004-05-19 04:14:20 +02:00
|
|
|
|
2006-07-14 21:52:29 +02:00
|
|
|
return ret;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define processDecodeInput() \
|
|
|
|
|
if(pc->lockQueue) { \
|
|
|
|
|
pc->queueLockState = PLAYER_QUEUE_LOCKED; \
|
|
|
|
|
pc->lockQueue = 0; \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task(); \
|
2004-02-24 00:41:20 +01:00
|
|
|
} \
|
|
|
|
|
if(pc->unlockQueue) { \
|
|
|
|
|
pc->queueLockState = PLAYER_QUEUE_UNLOCKED; \
|
|
|
|
|
pc->unlockQueue = 0; \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task(); \
|
2004-02-24 00:41:20 +01:00
|
|
|
} \
|
|
|
|
|
if(pc->pause) { \
|
|
|
|
|
pause = !pause; \
|
2007-08-12 21:15:06 +02:00
|
|
|
if (pause) { \
|
|
|
|
|
pc->state = PLAYER_STATE_PAUSE; \
|
|
|
|
|
} else { \
|
|
|
|
|
if (openAudioDevice(NULL) >= 0) { \
|
|
|
|
|
pc->state = PLAYER_STATE_PLAY; \
|
|
|
|
|
} else { \
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->erroredUrl, pc->utf8url); \
|
2004-03-20 20:47:05 +01:00
|
|
|
pc->error = PLAYER_ERROR_AUDIO; \
|
2004-11-03 03:11:08 +01:00
|
|
|
ERROR("problems opening audio device while playing \"%s\"\n", pc->utf8url); \
|
2007-04-03 22:22:10 +02:00
|
|
|
pause = -1; \
|
2004-03-20 20:47:05 +01:00
|
|
|
} \
|
|
|
|
|
} \
|
2004-02-24 00:41:20 +01:00
|
|
|
pc->pause = 0; \
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task(); \
|
2007-08-12 21:15:06 +02:00
|
|
|
if (pause == -1) { \
|
|
|
|
|
pause = 1; \
|
|
|
|
|
} else if (pause) { \
|
2005-12-17 01:56:48 +01:00
|
|
|
dropBufferedAudio(); \
|
|
|
|
|
closeAudioDevice(); \
|
|
|
|
|
} \
|
2004-02-24 00:41:20 +01:00
|
|
|
} \
|
|
|
|
|
if(pc->seek) { \
|
2005-03-21 04:54:14 +01:00
|
|
|
dropBufferedAudio(); \
|
2004-10-26 04:13:13 +02:00
|
|
|
if(decodeSeek(pc,dc,cb,&decodeWaitedOn,&next) == 0) { \
|
2004-05-19 04:14:20 +02:00
|
|
|
doCrossFade = 0; \
|
|
|
|
|
nextChunk = -1; \
|
2004-05-20 05:44:33 +02:00
|
|
|
bbp = 0; \
|
2004-05-19 04:14:20 +02:00
|
|
|
} \
|
2004-02-24 00:41:20 +01:00
|
|
|
} \
|
|
|
|
|
if(pc->stop) { \
|
2005-03-05 15:01:13 +01:00
|
|
|
dropBufferedAudio(); \
|
2004-02-24 00:41:20 +01:00
|
|
|
quitDecode(pc,dc); \
|
|
|
|
|
return; \
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static void decodeStart(PlayerControl * pc, OutputBuffer * cb,
|
|
|
|
|
DecoderControl * dc)
|
|
|
|
|
{
|
2006-07-14 21:52:29 +02:00
|
|
|
int ret;
|
2008-01-01 11:09:56 +01:00
|
|
|
int close_instream = 1;
|
2006-07-14 21:52:29 +02:00
|
|
|
InputStream inStream;
|
2006-07-20 18:02:40 +02:00
|
|
|
InputPlugin *plugin = NULL;
|
2007-12-28 03:56:25 +01:00
|
|
|
char path_max_tmp[MPD_PATH_MAX];
|
2004-04-11 20:27:12 +02:00
|
|
|
|
2007-12-28 03:56:25 +01:00
|
|
|
/* not actually sure why we convert between latin/UTF8 for URLs */
|
|
|
|
|
if (isRemoteUrl(pc->utf8url)) {
|
|
|
|
|
if (!utf8_to_latin1(path_max_tmp, pc->utf8url)) {
|
|
|
|
|
dc->error = DECODE_ERROR_FILE;
|
2008-01-01 11:09:56 +01:00
|
|
|
goto stop_no_close;
|
2007-12-28 03:56:25 +01:00
|
|
|
}
|
|
|
|
|
} else
|
|
|
|
|
rmp2amp_r(path_max_tmp,
|
|
|
|
|
utf8_to_fs_charset(path_max_tmp, pc->utf8url));
|
2004-05-31 13:42:46 +02:00
|
|
|
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(dc->utf8url, pc->utf8url);
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2007-12-28 03:56:25 +01:00
|
|
|
if (openInputStream(&inStream, path_max_tmp) < 0) {
|
2004-05-18 15:13:55 +02:00
|
|
|
dc->error = DECODE_ERROR_FILE;
|
2008-01-01 11:09:56 +01:00
|
|
|
goto stop_no_close;
|
2006-07-14 21:52:29 +02:00
|
|
|
}
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-14 21:52:29 +02:00
|
|
|
dc->state = DECODE_STATE_START;
|
2004-05-19 04:14:20 +02:00
|
|
|
dc->start = 0;
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
while (!inputStreamAtEOF(&inStream) && bufferInputStream(&inStream) < 0
|
|
|
|
|
&& !dc->stop) {
|
2004-10-16 14:22:19 +02:00
|
|
|
/* sleep so we don't consume 100% of the cpu */
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
my_usleep(10000);
|
2004-10-16 14:22:19 +02:00
|
|
|
}
|
2004-05-19 04:14:20 +02:00
|
|
|
|
2006-12-23 20:57:28 +01:00
|
|
|
/* for http streams, seekable is determined in bufferInputStream */
|
|
|
|
|
dc->seekable = inStream.seekable;
|
2008-04-12 06:07:44 +02:00
|
|
|
|
2008-01-01 11:09:56 +01:00
|
|
|
if (dc->stop)
|
|
|
|
|
goto stop;
|
2004-05-31 13:42:46 +02:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
ret = DECODE_ERROR_UNKTYPE;
|
|
|
|
|
if (isRemoteUrl(dc->utf8url)) {
|
2006-03-16 07:52:46 +01:00
|
|
|
unsigned int next = 0;
|
|
|
|
|
|
|
|
|
|
/* first we try mime types: */
|
2007-06-04 20:55:46 +02:00
|
|
|
while (ret && (plugin = getInputPluginFromMimeType(inStream.mime, next++))) {
|
2006-03-16 07:52:46 +01:00
|
|
|
if (!plugin->streamDecodeFunc)
|
|
|
|
|
continue;
|
|
|
|
|
if (!(plugin->streamTypes & INPUT_PLUGIN_STREAM_URL))
|
|
|
|
|
continue;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (plugin->tryDecodeFunc
|
|
|
|
|
&& !plugin->tryDecodeFunc(&inStream))
|
2006-03-16 07:52:46 +01:00
|
|
|
continue;
|
|
|
|
|
ret = plugin->streamDecodeFunc(cb, dc, &inStream);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* if that fails, try suffix matching the URL: */
|
2006-07-20 18:02:40 +02:00
|
|
|
if (plugin == NULL) {
|
2008-02-05 11:17:33 +01:00
|
|
|
const char *s = getSuffix(dc->utf8url);
|
2006-03-16 07:52:46 +01:00
|
|
|
next = 0;
|
2007-06-04 20:55:46 +02:00
|
|
|
while (ret && (plugin = getInputPluginFromSuffix(s, next++))) {
|
2006-03-16 07:52:46 +01:00
|
|
|
if (!plugin->streamDecodeFunc)
|
|
|
|
|
continue;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (!(plugin->streamTypes &
|
|
|
|
|
INPUT_PLUGIN_STREAM_URL))
|
2006-03-16 07:52:46 +01:00
|
|
|
continue;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (plugin->tryDecodeFunc &&
|
|
|
|
|
!plugin->tryDecodeFunc(&inStream))
|
2006-03-16 07:52:46 +01:00
|
|
|
continue;
|
2007-06-04 20:55:46 +02:00
|
|
|
ret = plugin->streamDecodeFunc(cb, dc, &inStream);
|
2006-03-16 07:52:46 +01:00
|
|
|
break;
|
|
|
|
|
}
|
2006-07-14 21:52:29 +02:00
|
|
|
}
|
2006-03-16 07:52:46 +01:00
|
|
|
/* fallback to mp3: */
|
2006-07-14 21:52:29 +02:00
|
|
|
/* this is needed for bastard streams that don't have a suffix
|
2006-07-20 18:02:40 +02:00
|
|
|
or set the mimeType */
|
|
|
|
|
if (plugin == NULL) {
|
2006-03-16 07:52:46 +01:00
|
|
|
/* we already know our mp3Plugin supports streams, no
|
|
|
|
|
* need to check for stream{Types,DecodeFunc} */
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
if ((plugin = getInputPluginFromName("mp3"))) {
|
|
|
|
|
ret = plugin->streamDecodeFunc(cb, dc,
|
|
|
|
|
&inStream);
|
|
|
|
|
}
|
2006-07-14 21:52:29 +02:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
} else {
|
2006-03-16 07:52:46 +01:00
|
|
|
unsigned int next = 0;
|
2008-02-05 11:17:33 +01:00
|
|
|
const char *s = getSuffix(dc->utf8url);
|
2006-03-16 07:52:46 +01:00
|
|
|
while (ret && (plugin = getInputPluginFromSuffix(s, next++))) {
|
2006-07-20 18:02:40 +02:00
|
|
|
if (!plugin->streamTypes & INPUT_PLUGIN_STREAM_FILE)
|
2006-03-16 07:52:46 +01:00
|
|
|
continue;
|
2007-06-25 15:22:51 +02:00
|
|
|
|
|
|
|
|
if (plugin->tryDecodeFunc &&
|
|
|
|
|
!plugin->tryDecodeFunc(&inStream))
|
2006-03-16 07:52:46 +01:00
|
|
|
continue;
|
2006-07-20 18:02:40 +02:00
|
|
|
|
2007-06-25 15:22:51 +02:00
|
|
|
if (plugin->fileDecodeFunc) {
|
2006-03-16 07:52:46 +01:00
|
|
|
closeInputStream(&inStream);
|
2008-01-01 11:09:56 +01:00
|
|
|
close_instream = 0;
|
2007-12-28 03:56:25 +01:00
|
|
|
ret = plugin->fileDecodeFunc(cb, dc,
|
|
|
|
|
path_max_tmp);
|
2007-06-25 15:22:51 +02:00
|
|
|
break;
|
|
|
|
|
} else if (plugin->streamDecodeFunc) {
|
|
|
|
|
ret = plugin->streamDecodeFunc(cb, dc, &inStream);
|
|
|
|
|
break;
|
2006-03-16 07:52:46 +01:00
|
|
|
}
|
|
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
}
|
2004-05-31 03:21:17 +02:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (ret < 0 || ret == DECODE_ERROR_UNKTYPE) {
|
2006-07-30 12:31:41 +02:00
|
|
|
pathcpy_trunc(pc->erroredUrl, dc->utf8url);
|
2008-01-01 11:09:56 +01:00
|
|
|
if (ret != DECODE_ERROR_UNKTYPE)
|
2006-07-20 18:02:40 +02:00
|
|
|
dc->error = DECODE_ERROR_FILE;
|
2008-01-01 11:09:56 +01:00
|
|
|
else
|
2006-07-14 21:52:29 +02:00
|
|
|
dc->error = DECODE_ERROR_UNKTYPE;
|
2004-05-18 15:13:55 +02:00
|
|
|
}
|
2008-01-01 11:09:56 +01:00
|
|
|
|
|
|
|
|
stop:
|
|
|
|
|
if (close_instream)
|
|
|
|
|
closeInputStream(&inStream);
|
|
|
|
|
stop_no_close:
|
|
|
|
|
dc->state = DECODE_STATE_STOP;
|
|
|
|
|
dc->stop = 0;
|
2004-05-18 15:13:55 +02:00
|
|
|
}
|
|
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
static void * decoder_task(mpd_unused void *unused)
|
2006-07-20 18:02:40 +02:00
|
|
|
{
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
OutputBuffer *cb = &(getPlayerData()->buffer);
|
|
|
|
|
PlayerControl *pc = &(getPlayerData()->playerControl);
|
|
|
|
|
DecoderControl *dc = &(getPlayerData()->decoderControl);
|
|
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
|
if (dc->start || dc->seek) {
|
|
|
|
|
decodeStart(pc, cb, dc);
|
|
|
|
|
} else if (dc->stop) {
|
|
|
|
|
dc->state = DECODE_STATE_STOP;
|
|
|
|
|
dc->stop = 0;
|
|
|
|
|
decoder_wakeup_player();
|
|
|
|
|
} else {
|
|
|
|
|
decoder_sleep();
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
}
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
}
|
2004-02-24 00:41:20 +01:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
void decoderInit(void)
|
|
|
|
|
{
|
|
|
|
|
pthread_attr_t attr;
|
|
|
|
|
pthread_t decoder_thread;
|
|
|
|
|
|
|
|
|
|
pthread_attr_init(&attr);
|
|
|
|
|
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
|
|
|
|
|
if (pthread_create(&decoder_thread, &attr, decoder_task, NULL))
|
|
|
|
|
FATAL("Failed to spawn decoder task: %s\n", strerror(errno));
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
static void advanceOutputBufferTo(OutputBuffer * cb, PlayerControl * pc,
|
2008-04-12 06:08:12 +02:00
|
|
|
int *currentChunkSent, int to)
|
2004-06-07 14:11:57 +02:00
|
|
|
{
|
2006-07-20 18:02:40 +02:00
|
|
|
while (cb->begin != to) {
|
2008-04-12 06:08:12 +02:00
|
|
|
if ((unsigned)cb->begin + 1 >= buffered_chunks)
|
2004-06-07 14:11:57 +02:00
|
|
|
cb->begin = 0;
|
2008-04-12 06:08:12 +02:00
|
|
|
else
|
|
|
|
|
cb->begin++;
|
2004-06-06 21:41:03 +02:00
|
|
|
}
|
2004-06-06 18:42:14 +02:00
|
|
|
}
|
|
|
|
|
|
2006-08-20 02:50:44 +02:00
|
|
|
static void decodeParent(PlayerControl * pc, DecoderControl * dc, OutputBuffer * cb)
|
2006-07-20 18:02:40 +02:00
|
|
|
{
|
2004-05-19 04:14:20 +02:00
|
|
|
int pause = 0;
|
|
|
|
|
int quit = 0;
|
2008-04-12 06:06:17 +02:00
|
|
|
unsigned int bbp = buffered_before_play;
|
2004-05-19 04:14:20 +02:00
|
|
|
int doCrossFade = 0;
|
2008-04-12 06:06:17 +02:00
|
|
|
unsigned int crossFadeChunks = 0;
|
|
|
|
|
unsigned int fadePosition;
|
2004-05-19 04:14:20 +02:00
|
|
|
int nextChunk = -1;
|
2008-04-12 06:06:17 +02:00
|
|
|
unsigned int test;
|
2006-07-20 18:02:40 +02:00
|
|
|
int decodeWaitedOn = 0;
|
2008-01-01 11:10:02 +01:00
|
|
|
static const char silence[CHUNK_SIZE];
|
2004-06-03 14:34:25 +02:00
|
|
|
double sizeToTime = 0.0;
|
2004-06-07 14:11:57 +02:00
|
|
|
int currentChunkSent = 1;
|
2008-04-12 06:06:17 +02:00
|
|
|
unsigned int end;
|
2004-06-10 21:48:53 +02:00
|
|
|
int next = -1;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
if (waitOnDecode(pc, dc, cb, &decodeWaitedOn) < 0)
|
|
|
|
|
return;
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
pc->elapsedTime = 0;
|
2004-05-19 04:14:20 +02:00
|
|
|
pc->state = PLAYER_STATE_PLAY;
|
|
|
|
|
pc->play = 0;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task();
|
2004-05-20 05:44:33 +02:00
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
while ((unsigned)cb->end - cb->begin < bbp &&
|
2006-07-20 18:02:40 +02:00
|
|
|
cb->end != buffered_chunks - 1 &&
|
|
|
|
|
dc->state != DECODE_STATE_STOP) {
|
2004-05-19 04:14:20 +02:00
|
|
|
processDecodeInput();
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
player_sleep();
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
while (!quit) {
|
2004-05-19 04:14:20 +02:00
|
|
|
processDecodeInput();
|
2006-07-20 18:02:40 +02:00
|
|
|
handleDecodeStart();
|
|
|
|
|
if (dc->state == DECODE_STATE_STOP &&
|
|
|
|
|
pc->queueState == PLAYER_QUEUE_FULL &&
|
|
|
|
|
pc->queueLockState == PLAYER_QUEUE_UNLOCKED) {
|
2004-06-10 21:48:53 +02:00
|
|
|
next = cb->end;
|
2004-05-19 04:14:20 +02:00
|
|
|
dc->start = 1;
|
|
|
|
|
pc->queueState = PLAYER_QUEUE_DECODE;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task();
|
|
|
|
|
player_wakeup_decoder_nb();
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
if (next >= 0 && doCrossFade == 0 && !dc->start &&
|
|
|
|
|
dc->state != DECODE_STATE_START) {
|
2004-05-19 04:14:20 +02:00
|
|
|
nextChunk = -1;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (isCurrentAudioFormat(&(cb->audioFormat))) {
|
2004-05-19 04:14:20 +02:00
|
|
|
doCrossFade = 1;
|
2006-07-20 18:02:40 +02:00
|
|
|
crossFadeChunks =
|
|
|
|
|
calculateCrossFadeChunks(pc,
|
|
|
|
|
&(cb->
|
|
|
|
|
audioFormat));
|
|
|
|
|
if (!crossFadeChunks
|
|
|
|
|
|| pc->crossFade >= dc->totalTime) {
|
2004-05-19 04:14:20 +02:00
|
|
|
doCrossFade = -1;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
} else
|
|
|
|
|
doCrossFade = -1;
|
2004-05-19 04:14:20 +02:00
|
|
|
}
|
2004-06-10 21:48:53 +02:00
|
|
|
|
2006-07-14 20:01:32 +02:00
|
|
|
/* copy these to local variables to prevent any potential
|
2006-07-20 18:02:40 +02:00
|
|
|
race conditions and weirdness */
|
2004-06-10 21:48:53 +02:00
|
|
|
end = cb->end;
|
|
|
|
|
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
if (pause)
|
|
|
|
|
player_sleep();
|
|
|
|
|
else if (cb->begin != end && cb->begin != next) {
|
2006-07-20 18:02:40 +02:00
|
|
|
if (doCrossFade == 1 && next >= 0 &&
|
|
|
|
|
((next > cb->begin &&
|
|
|
|
|
(fadePosition = next - cb->begin)
|
|
|
|
|
<= crossFadeChunks) ||
|
|
|
|
|
(cb->begin > next &&
|
|
|
|
|
(fadePosition = next - cb->begin +
|
|
|
|
|
buffered_chunks) <= crossFadeChunks))) {
|
|
|
|
|
if (nextChunk < 0) {
|
2004-05-19 04:14:20 +02:00
|
|
|
crossFadeChunks = fadePosition;
|
|
|
|
|
}
|
2004-06-10 21:48:53 +02:00
|
|
|
test = end;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (end < cb->begin)
|
|
|
|
|
test += buffered_chunks;
|
|
|
|
|
nextChunk = cb->begin + crossFadeChunks;
|
2008-04-12 06:06:52 +02:00
|
|
|
if ((unsigned)nextChunk < test) {
|
|
|
|
|
if ((unsigned)nextChunk >= buffered_chunks) {
|
2006-07-20 18:02:40 +02:00
|
|
|
nextChunk -= buffered_chunks;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
pcm_mix(cb->chunks +
|
|
|
|
|
cb->begin * CHUNK_SIZE,
|
|
|
|
|
cb->chunks +
|
|
|
|
|
nextChunk * CHUNK_SIZE,
|
|
|
|
|
cb->chunkSize[cb->begin],
|
|
|
|
|
cb->chunkSize[nextChunk],
|
|
|
|
|
&(cb->audioFormat),
|
|
|
|
|
((float)fadePosition) /
|
|
|
|
|
crossFadeChunks);
|
|
|
|
|
if (cb->chunkSize[nextChunk] >
|
|
|
|
|
cb->chunkSize[cb->begin]
|
|
|
|
|
) {
|
2004-05-19 04:14:20 +02:00
|
|
|
cb->chunkSize[cb->begin]
|
2006-07-20 18:02:40 +02:00
|
|
|
= cb->chunkSize[nextChunk];
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
} else {
|
|
|
|
|
if (dc->state == DECODE_STATE_STOP) {
|
2004-05-19 04:14:20 +02:00
|
|
|
doCrossFade = -1;
|
2006-07-20 18:02:40 +02:00
|
|
|
} else
|
|
|
|
|
continue;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
|
|
|
|
}
|
2004-05-30 15:33:13 +02:00
|
|
|
pc->elapsedTime = cb->times[cb->begin];
|
2004-05-19 04:14:20 +02:00
|
|
|
pc->bitRate = cb->bitRate[cb->begin];
|
2006-07-20 18:02:40 +02:00
|
|
|
pcm_volumeChange(cb->chunks + cb->begin *
|
|
|
|
|
CHUNK_SIZE,
|
|
|
|
|
cb->chunkSize[cb->begin],
|
|
|
|
|
&(cb->audioFormat),
|
|
|
|
|
pc->softwareVolume);
|
|
|
|
|
if (playAudio(cb->chunks + cb->begin * CHUNK_SIZE,
|
|
|
|
|
cb->chunkSize[cb->begin]) < 0) {
|
2004-05-19 04:14:20 +02:00
|
|
|
quit = 1;
|
|
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
pc->totalPlayTime +=
|
|
|
|
|
sizeToTime * cb->chunkSize[cb->begin];
|
2008-04-12 06:06:52 +02:00
|
|
|
if ((unsigned)cb->begin + 1 >= buffered_chunks) {
|
2004-05-19 04:14:20 +02:00
|
|
|
cb->begin = 0;
|
2006-07-20 18:02:40 +02:00
|
|
|
} else
|
|
|
|
|
cb->begin++;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
player_wakeup_decoder_nb();
|
2007-02-11 21:36:26 +01:00
|
|
|
} else if (cb->begin != end && cb->begin == next) {
|
2006-07-20 18:02:40 +02:00
|
|
|
if (doCrossFade == 1 && nextChunk >= 0) {
|
|
|
|
|
nextChunk = cb->begin + crossFadeChunks;
|
2007-02-11 21:36:26 +01:00
|
|
|
test = end;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (end < cb->begin)
|
|
|
|
|
test += buffered_chunks;
|
2008-04-12 06:06:52 +02:00
|
|
|
if ((unsigned)nextChunk < test) {
|
|
|
|
|
if ((unsigned)nextChunk >= buffered_chunks) {
|
2004-05-19 04:14:20 +02:00
|
|
|
nextChunk -= buffered_chunks;
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
advanceOutputBufferTo(cb, pc,
|
|
|
|
|
¤tChunkSent,
|
|
|
|
|
nextChunk);
|
|
|
|
|
}
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
while (pc->queueState == PLAYER_QUEUE_DECODE ||
|
|
|
|
|
pc->queueLockState == PLAYER_QUEUE_LOCKED) {
|
2004-05-19 04:14:20 +02:00
|
|
|
processDecodeInput();
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
player_sleep();
|
2004-05-19 04:14:20 +02:00
|
|
|
}
|
2006-07-20 18:02:40 +02:00
|
|
|
if (pc->queueState != PLAYER_QUEUE_PLAY) {
|
2004-02-24 00:41:20 +01:00
|
|
|
quit = 1;
|
|
|
|
|
break;
|
2006-07-20 18:02:40 +02:00
|
|
|
} else {
|
2004-06-10 21:48:53 +02:00
|
|
|
next = -1;
|
2006-07-20 18:02:40 +02:00
|
|
|
if (waitOnDecode(pc, dc, cb, &decodeWaitedOn) <
|
|
|
|
|
0) {
|
2006-07-14 21:52:29 +02:00
|
|
|
return;
|
|
|
|
|
}
|
2004-05-19 04:14:20 +02:00
|
|
|
nextChunk = -1;
|
|
|
|
|
doCrossFade = 0;
|
|
|
|
|
crossFadeChunks = 0;
|
|
|
|
|
pc->queueState = PLAYER_QUEUE_EMPTY;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
wakeup_main_task();
|
2004-05-18 21:32:05 +02:00
|
|
|
}
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
} else if (dc->state == DECODE_STATE_STOP && !dc->start) {
|
2004-05-19 04:14:20 +02:00
|
|
|
quit = 1;
|
|
|
|
|
break;
|
2006-07-20 18:02:40 +02:00
|
|
|
} else {
|
2007-01-24 03:56:45 +01:00
|
|
|
/*DEBUG("waiting for decoded audio, play silence\n");*/
|
2006-07-20 18:02:40 +02:00
|
|
|
if (playAudio(silence, CHUNK_SIZE) < 0)
|
|
|
|
|
quit = 1;
|
2004-05-19 04:14:20 +02:00
|
|
|
}
|
|
|
|
|
}
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-20 18:02:40 +02:00
|
|
|
quitDecode(pc, dc);
|
2004-05-19 04:14:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* decode w/ buffering
|
|
|
|
|
* this will fork another process
|
|
|
|
|
* child process does decoding
|
|
|
|
|
* parent process does playing audio
|
|
|
|
|
*/
|
2006-08-08 04:23:21 +02:00
|
|
|
void decode(void)
|
2006-07-20 18:02:40 +02:00
|
|
|
{
|
|
|
|
|
OutputBuffer *cb;
|
|
|
|
|
PlayerControl *pc;
|
|
|
|
|
DecoderControl *dc;
|
2004-05-19 04:14:20 +02:00
|
|
|
|
|
|
|
|
cb = &(getPlayerData()->buffer);
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2004-05-19 04:14:20 +02:00
|
|
|
cb->begin = 0;
|
|
|
|
|
cb->end = 0;
|
|
|
|
|
pc = &(getPlayerData()->playerControl);
|
|
|
|
|
dc = &(getPlayerData()->decoderControl);
|
|
|
|
|
dc->error = 0;
|
2006-07-14 21:52:29 +02:00
|
|
|
dc->seek = 0;
|
|
|
|
|
dc->stop = 0;
|
2004-05-20 05:44:33 +02:00
|
|
|
dc->start = 1;
|
Initial cut of fork() => pthreads() for decoder and player
I initially started to do a heavy rewrite that changed the way processes
communicated, but that was too much to do at once. So this change only
focuses on replacing the player and decode processes with threads and
using condition variables instead of polling in loops; so the changeset
itself is quiet small.
* The shared output buffer variables will still need locking
to guard against race conditions. So in this effect, we're probably
just as buggy as before. The reduced context-switching overhead of
using threads instead of processes may even make bugs show up more or
less often...
* Basic functionality appears to be working for playing local (and NFS)
audio, including:
play, pause, stop, seek, previous, next, and main playlist editing
* I haven't tested HTTP streams yet, they should work.
* I've only tested ALSA and Icecast. ALSA works fine, Icecast
metadata seems to get screwy at times and breaks song
advancement in the playlist at times.
* state file loading works, too (after some last-minute hacks with
non-blocking wakeup functions)
* The non-blocking (*_nb) variants of the task management functions are
probably overused. They're more lenient and easier to use because
much of our code is still based on our previous polling-based system.
* It currently segfaults on exit. I haven't paid much attention
to the exit/signal-handling routines other than ensuring it
compiles. At least the state file seems to work. We don't
do any cleanups of the threads on exit, yet.
* Update is still done in a child process and not in a thread.
To do this in a thread, we'll need to ensure it does proper
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
locking and communication with the main thread; but should
require less memory in the end because we'll be updating
the database "in-place" rather than updating a copy and
then bulk-loading when done.
* We're more sensitive to bugs in 3rd party libraries now.
My plan is to eventually use a master process which forks()
and restarts the child when it dies:
master - just does waitpid() + fork() in a loop
\- main thread
\- decoder thread
\- player thread
At the beginning of every song, the main thread will set
a dirty flag and update the state file. This way, if we
encounter a song that triggers a segfault killing the
main thread, the master will start the replacement main
on the next song.
* The main thread still wakes up every second on select()
to check for signals; which affects power management.
[merged r7138 from branches/ew]
git-svn-id: https://svn.musicpd.org/mpd/trunk@7240 09075e82-0dd4-0310-85a5-a0d7c8717e4f
2008-04-12 06:08:00 +02:00
|
|
|
do { player_wakeup_decoder(); } while (dc->start);
|
2004-02-24 00:41:20 +01:00
|
|
|
|
2006-07-14 21:52:29 +02:00
|
|
|
decodeParent(pc, dc, cb);
|
2004-02-24 00:41:20 +01:00
|
|
|
}
|