Re: [Rhythmbox-devel] Seamless playing

[John Russell <drjimmy42 yahoo com>]

On a related issue, there is a media player out there, the name of which
escapes me for the moment that fades one track out and the next in when
you change tracks.  This doesn't happen when one song ends and another
begins, but only when you click next, or double click on a completely
different file.  It avoids the jarring stopping and starting of songs
when you are skipping around looking for something. 

Personally, I could see how the fade in would be kind of annoying but
the fade out was really sweet.  It wasn't long, just a second or two at
the most, but it was a really nice piece of ear candy that makes the app
look really polished.  I'm not sure if this is related to the logic for
seamless playback, but both would be really cool.

John

On Thu, 2004-02-12 at 23:08, Colin Walters wrote:
> 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.
-- 
If you're not part of the solution, you're part of the precipitate.