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

[Ronald Bultje <rbultje ronald bitfreak net>]

Hi Jorn,

On Fri, 7 May 2004, Jorn Baayen wrote:
> Muine currently defaults to using a xine-lib backend. Using GStreamer
> would be a lot nicer obviously, but there currently are a couple of
> issues preventing it from being used succesfully in Muine. Details can
> be found on this page:
> http://huizen.dds.nl/~jbaayen/gstreamer-problems.html.

"Seeking mp3 streams is unreliable, sometimes instead of seeking to the
specified position it skips back to the beginning of the stream, or it
seeks backwards a few seconds. This happens on both fixed and variable
bitrate mp3s. It is not hard to reproduce- I can offer test files if
needed."

Please file one or two on bugzilla. I haven't seen this before, and will
help to fix it.

"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.

It probably sounds hackish. Sorry for that. I don't think there's an easy
solution. Autoplugging just isn't fast enough yet... :-(.

(I'd try out Muine if mono wouldn't require an incredible amount of
diskspace; my laptop HD is full... :-(. The screenshots of Muine look
really cool, though.)

Ronald