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

List:       kde-multimedia
Subject:    Re: MAS in KDE
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2003-03-05 8:25:09
[Download RAW message or body]

   Hi!

On Wed, Mar 05, 2003 at 12:02:46AM -0800, Neil Stevens wrote:
> On Tuesday March 04, 2003 11:49, Stefan Westerfeld wrote:
> > On Tue, Mar 04, 2003 at 04:12:15PM -0800, Neil Stevens wrote:
> > > We already know we are going to choose a system.  We will already have
> > > to wrap it.  CSL gives us nothing beyond that.
> >
> > And preferably I am working on choosing an open, interoperable solution
> > for sound input/output in KDE3.2 ; CSL was just a suggestion I made, and
> > PortAudio might be an even better suggestion.
> >
> > Isn't that choosing a system? I think we should not try to choose a
> > complete media framework (such as GStreamer) and try to solve everything
> > with it.
> 
> But there already demonstrated needs for a complete framework throughout 
> KDE and kdemultimedia.  I need video in Kaboodle.  Charles Samuels filters 
> and the equalizer in Noatun.  Benjamin Meyer needs audio compression in 
> KAudioCreator.
> 
> Going with some featureless sound server will not meet these needs.  Even 
> if we use one of them, we still have to put one of those frameworks on top 
> of it.

So whats the problem of doing this? For KDE3.2, there will still be aRts (as
long as KDE3 has to stay BC, we need to have aRts). Its just that using
PortAudio

a) aRts can send data to any destination PortAudio supports (for instance
   JACK is one of the targets that we currently don't support that would
   be gained by using PortAudio)

b) those apps that _only_ want to output audio data and nothing else (and
   there are some of them) can avoid using two cascaded output systems
   (i.e. kfrob -> aRts -> ALSA or kfrob -> aRts -> JACK) but instead can
   send the data directly, if they want to (kfrob -> ALSA)

This is beneficial for:
 - the quality of the aRts implementation (because we will have our drivers
   in PortAudio, where they get other developers to work on them as well)
 - the sound quality (no double-resampling if you want to output data with
   a sampling rate that aRts doesn't currently use)
 - the performance

I see no disadvantages, execept for the work to write the code. But well, I
am not telling you to do this, so you need not complain about it, right? ;)

> > If we need something (like: input/output of sound streams), we should
> > choose something that fills this need, or implement something that does.
> > I have identified a need for input/output of sound streams (see CSL
> > paper), and I am trying to choose something that fills this need for
> > KDE.
> >
> > If I am doing something that makes no sense to you, let me know. ;)
> 
> You're making sense to me just fine.  I just wish you could see that KDE 
> needs more than just basic input and output of sound streams.

You probably don't mean that I don't see it (for had I not seen it, I probably
would not have written aRts in the first place), but that I don't take this
into account in the right way.

Thus I'd like to know what would be the right thing to do, instead of a reason
why you think I am doing the wrong thing (supposedly: blindness for the obvious
facts). What are the obvious things I am missing that make depending on
PortAudio in KDE3.2 a problem (while keeping aRts around as it has always
been)?

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
kde-multimedia mailing list
kde-multimedia@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]