Re: [Muine] Re: Muine (!) Relicensing



On Tue, 2005-01-11 at 12:03 -0800, Tamara wrote:
> > > Splitting off "MusicManager" and "MusicPlayer" would *reduce* the size
> > > of Muine and make it *simpler*. It would also be a plus for Beagle as
> > > well as RB. I would be doing it for the reason of simplification and
> > > reducing bloat.
> > 
> > It would only take out the few hundred line Player.cs, not something I
> > would call a considerable reduction ..
> 
> Um... no. It would remove all the metadata, GStreamer, and Xine code
> from libmuine as well. Managing the Song and Cover Databases would
> move as well as Amazon Cover / CoverGetter stuff. It would split Muine
> in two.

You want to move the DB stuff as well? There's even less point there ...
RB has much higher requirements for DB than Muine. Muine just uses a
very, very simple and light gdbm database to do the job- using the same
monstrous DB backend as RB uses would slow things down.

(Also - The xine and our own metadata code will be obsolete soon.)

> > Yea, but either way, it is bloat for something that is already way
> > simple. I mean, basically all we need to do for GStreamer playback is to
> > create a 'playbin' element. Why should this 'playbin' element be
> > embedded in all kinds of fluff, and thereby creating regressions for all
> > the using apps as well? (non-instant depausing (see later in this mail)
> > is the first to spring to my mind)
> 
> Because it would manage all music playing on a system. The app would
> request a list of songs from MusicManager, the user would select one
> and request the MusicPlayer play it. Also, MusicPlayer would
> dynamically switch between Xine and GStreamer support.

Way over the top is my opinion, as you know by now. :)

> > > It wouldn't send that much data over D-Bus anyway, just status changes
> > > and exceptions. You wouldn't have to update it every second or
> > > anything like that.
> >
> > > > The "MusicPlayer" would have to be quite sophisticated for starters,
> > > > because you need to support having more than one stream open at a time
> > > > (for instance one from muine paused, and one from your-random-other-app
> > > > playing, for instance). Etc.
> > >
> > > You wouldn't need more than one stream open at a time. If the user
> > > wants to play two song simultaneously (e.g. mixing), then MusicPlayer
> > > would be not the right place to do that.
> > >
> > > Starting playing in one app would pause it in the other. To resume,
> > > the app would just send the play request and the position to start
> > > playing at.
> > 
> > Yea, I know that seems possible in theory. But in practice it is very
> > hard or impossible to seek back to *exactly* where you left off in the
> > case of VBR files, and it's not exactly responsive if you have to open
> > and decode the file first.
> 
> Couldn't we just use a file offset? I admit I don't know that much
> about music files...

You can't just do that, because in the simplest case you first need to
read the file's header. In a VBR case, you need to know what the bitrate
at that point is. In a chained ogg case, you need to know what part you
are in with what samplerate, etc.

> > Really, as every app has their own playback requirements, it is much
> > better for them to talk to GStreamer in their own way. For instance, an
> > internet radio player will have much different requirements from a
> > regular player.
> > 
> > I've been working a little on an iradio player in the spirit of Muine,
> > and the thing I'm thinking of doing is sending a signal to the bus,
> > something like "MusicStartedPlaying". Which the other app would pick up,
> > and subsequently pause their stream.
> 
> But it would make good sense for the multitude of normal music players
> to share a common backend. A change occurring in one might as well
> propagate to the others. Therefore a user would just use the front-end
> of her choice (panel applet, small app like Muine, more robust app
> like RhythmBox) and not have to remanage her music in each program.

Having the same user use different music playback apps is definetely not
the kind of user Muine targets. 


Jorn




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]