Some ideas for the aRts-replacement

Neil Stevens neil at
Mon Feb 23 17:55:57 GMT 2004

Hash: SHA1

On Monday February 23, 2004 8:40 am, Dik Takken wrote:
> Hi All,
> I have been following the discussions on this list about the future of
> Arts in KDE, and have been thinking about what we could do.
> Please read my idea about replacing the current sound API with something
> new that is not Arts, not GStreamer or anything else.
> This API has the following properties:
> * Applications that just need a 'play this' command will get it.
> * Applications that want to fiddle with equalisers, mixing and so on
> will also find all they need.
> * The API is a complete abstraction of the underlying technology. Using
> Arts, GStreamer or just plain ALSA does not change anything for the
> application programmer.
> * The API and it's implementation can be made very flexible. When there
> is no Arts or GStreamer available, it will still work.
> * Give the user more control of what happens to sound output of
> applications and what sound system is used by KDE
> (Arts,GStreamer,whatever).

If you do this, you're just writing GStreamer on top of GStreamer!

The fact is, KDE needs to *depend* upon a standard set of decoders and 
sound output.  Unless this support is *guaranteed*, applications will be 
forced to go reinvent the wheel over and over again, getting the support 
that is lacking in kdelibs.

More abstraction isn't what's needed.   Standardization is what is needed.  
Without a standard, guaranteed set of features, featureful application 
development is hindered.

The lowest common denominator isn't the answer either, becuase then every 
app who wants higher than that will just reinvent it anyway!

- -- 
Neil Stevens - neil at

"It's snowing, it's snowing! God, I hate this weather."
    They Might Be Giants, __New York City__
Version: GnuPG v1.2.3 (FreeBSD)


More information about the kde-multimedia mailing list