[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Proposal: libunixmm.so (about the Comparison: MAS, GStreamer,
From:       Scott Wheeler <wheeler () kde ! org>
Date:       2004-09-09 21:43:17
Message-ID: 200409092343.17540.wheeler () kde ! org
[Download RAW message or body]

On Thursday 09 September 2004 23:16, Christian Esken wrote:
> On Thursday 09 September 2004 21:54, Scott Wheeler wrote:
> > On Thursday 09 September 2004 21:48, Christian Esken wrote:
> > 
> > > Could we an informal voting about that? I would like to see a clearer 
> > > picture.  Just stand up and mail "I agree" or "I do NOT agree"
> > 
> > Voting hasn't ever worked in KDE and really seems pretty pointless.
> 
> So you want to go the KDE way?  The one who takes the lead has the power.
> But then the discussions on this mailing-list are futile and just wasted 
> time: 

Well, uhm, this is the KDE project.  ;-)  Voting simply isn't effective 
without the assumption that everyone's vote counts and counts the same.  OSS 
never works that way.  It's always based on a concensus of those doing the 
work.  A vote wouldn't have any authority; I can't imagine anyone saying, 
"Oh, well, we voted; I guess that's that."

> We are happily wasting time to prove to each other that there is no optimal 
> sound system: One has no network transparency, the other one has not enough 
> developer support, the other one lacks realtime performance, the next cannot 
> capture audio data, and so on, and so on. 
>
> Well, thats the point. We have not agreed on a media backend either.
> We have not even agreed whether we need to select a backend.
> 
> With the current state of affairs (kde-multimedia has no common goal), I 
> would be happy if somebody would just go the KDE way: Take the lead, and try 
> out some backends. Like doing a hacked up version of KAudioPlayer that uses 
> MAS or GStreamer as backend.  I'll probably do that myself ... even if half 
> of the kde-multimedia people will after that throw stones at me :) 

But we've already done that basically.  That's the whole point.  The interface 
is already there, implementations for aRts and aKode are already there and 
I've started on one for GStreamer; there's an empty dir for NMM.

You're also really mixing up different issues here.  As I understand things 
NMM can output to multiple soundservers, as can GStreamer.

MAS doesn't offer a lot of what we need from a framework at the moment so it 
can only be considered as a sound server (now).

The sound server decision is one that's trivialized by having an abstract API, 
and really the only one here arguing against that is Charles.

It really doesn't make sense to get into worrying about the sound server or 
how we're going to handle /dev/dsp at the moment.  That's a detail that in 
every case is abstracted away by the backends -- whether we chose one 
specifically or three it's always still not something we deal with directly.

-Scott
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]