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

List:       kde-multimedia
Subject:    Re: Some ideas for the aRts-replacement
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2004-02-20 8:47:00
Message-ID: 20040220084700.GD34849 () xs4all ! nl
[Download RAW message or body]

On Fri, Feb 20, 2004 at 02:09:40AM +0100, Koos Vriezen wrote:
> > Which basically means we'd be where we are now, but we'd have introduced 
> > another layer and something else for us to do a bad job of maintaining.
> 
> Not quite, knotify doesn't depend on arts (was the subject of the
> original posting :) 

Putting this in a plan (I think alex ideas can fit in this):

1 Goals:
a Make everybody happy
  a1 Lots of possible choices
  a2 Load only what you need
b Make it working ASAP
  b1 Use what's already there and working

2 Implementation
a A simple sound server wrapper, using plugins. Used by knotify. Can play
  raw audio formats
   a1 ESD
   a2 ALSA
   a3 arts (because it's a sound server as well)
   a4 others like MAS/Jack/.. later
b KSoundDSP wrapper for artsdsp/esddsp or rewrite on top of 2a
c Keep arts on top of 2a or as 2a3 and make a frontend for loading
  and unloading (make it something that xine-lib//mplayer/gstreamer is)
d See if gstreamer can replace arts (there is no time pressure here)

3 Scenario's
For users that use arts based players (noatun, amarok, juk) they can 
configure either 2a1/2a2 and 2c, or 2a3. So yes, for kdemultimedia 
developers/users there is little change. Developers can concentrate on
gstreamer.
For users that use only system sounds and/or xine/mplayer based players,
configure 2a1/2a2, but 2a3 will work too and 2a4 might work someday. This
is a big gain for these users.


Koos
_______________________________________________
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]