Re: [Muine] Re: Introducing Muine, Rhythmbox in 2.8 and other things

["Ronald S. Bultje" <R S Bultje students uu nl>]

Hi Jorn,

On Sat, 2004-05-08 at 12:42, Jorn Baayen wrote:
> After some more research it turned out the problem is slighty different;
> GstPlay's time_tick event does not return the right time after seeking
> an mp3 file. See:
> http://bugzilla.gnome.org/show_bug.cgi?id=142127

So, given that that was already fixed recently, does this mean mp3
playback now works as expected (and as it does here locally)? If not,
please make more bug reports, we'll be happy to fix them.

> > "Changing streams is relatively slow, it usually takes ~ 1 second, whereas
> > this is more or less instant using xine-lib. This has a major impact on
> > the user experience."
> > 
> > If you want to know a possible way to fix this: you would basically need
> > to "queue up" the next/previous song to prevent this. The GStreamer model
> > focusses on playback of a single media stream. Playlists are basically on
> > the border of GStreamer's core scope, probably right outside it. Queueing
> > up means that you already create a pipeline element (or whatever
> > descendant of that you use in Muine) of another song, if possible with a
> > queue between the decoder (or the autoplugger) and the audio sink element.
> > Set the left part (before the queue) to playing, and possibly wait for the
> > 'full' signal on the queue. Then set back to pause (saves CPU cycles). Set
> > back to playing if you change songs. Now, the transition will be instant.
> 
> Unfortunately I can't predict what song the user is going to play next-
> any song can be chosen to be played at any time ..

Is this, as #133778 suggests, related to the audiosink in use? And is
this reproduceable with current CVS? If so, I'd be happy to fix this as
well. Maybe autoplugging isn't as slow as I thought. :).

Ronald