On Thu, 2004-02-12 at 21:09, Andreas Bombe wrote:
> ... is something I'm going to work on, now that I've got gstreamer 0.7.4
> working with rhythmbox 0.7, mostly.
Cool.
> I haven't yet delved into the sources, but from what I gather acquiring
> data, decoding and playing to audio device is a completely self
> contained task handed to the player backend.
Right.
> If those backends don't support seamless playback of multiple audio
> files (do gstreamer or xine have provisions for this?)
I don't know about Xine, but GStreamer doesn't have a nice library for
this, but it should be possible to implement using GStreamer.
> I'll have to
> split that into a decode to audio samples part and a samples output
> part. Then I could handle the samples in rb independently of the
> backends, opening the next file to play ahead of time and switch to the
> new sample stream right when the first file finished decoding.
One thing I've really been meaning to investigate more is converting
rb-player-gst.c over to GstPlay. I think that would basically just
involve porting the internet radio bits over to GstPlay. The reason I
mention this is because gapless playback is something that all the
GStreamer-based players are going to be interested in, and it makes
sense to put it in the existing GStreamer playback library.
Once we used GstPlay, then we'd be much closer to having visualizations
and whatnot.
As for implementation, one approach would be a pipeline like this:
{ gnomevfssrc ! queue } ! spider ! volume ! sink
{ gnomevfssrc ! queue } ! fakesink
The top pipeline would be the current, and the bottom would be the next
queued song. Once you start playing a song, you start the whole top
pipeline, and also set the bottom first thread to PLAYING, and let the
queue fill up. Then when the first song ends, you destroy the top
pipeline, make the bottom pipeline the top pipeline, recreate the
spider, volume, and sink, and create a new instance of the pipeline for
the bottom.
Designing an API for this is tricky because you need to think about
threading and asynchronous events and stuff.
This is a digitally signed message part