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