Some ideas for the aRts-replacement (was: aRts needs to be replaced (was Re: Disabling aRts in knotify))

Neil Stevens neil at
Thu Feb 19 23:31:16 GMT 2004

Hash: SHA1

I urge all KDE people interested in a KDE 4 replacement of aRts to go back 
and read the old threads I led examining what's out there.  We went over 
this in-depth, but I'm sure many people coming here from kde-core-devel 
didn't see it.

Two points I'll make.  One:  Back then, GStreamer was superior to aRts in 
every way but one: dependence in glib 2.  However, as the maintainer of 
aRts has decided to make aRts depend on glib 2 as well, that is no longer 
a valid argument for aRts against glib.

So, unless someone can find an extensible system of decoders that outputs 
to a variety of systems that doesn't use glib, GStreamer and its 
in-development Qt-based interface should be considered for KDE 4.

Two:  A dumb sound server alone is not an option for KDE.  Here's why: For 
apps to play sound to a device they need to store it somehow.  In order to 
keep that storage from growing to an unreasonable size, we need to 
compress that audio.  The best audio compression systems require special 
libraries to decode the sound.  Therefore, in a KDE dependent only on a 
dumb server, KDE apps using sound would each need to include their own 
decoder libraries and re-write their interfacing between the decoder and 
the dumb server.

I suggest that such an outcome will lead to massively duplicated code and 
the attendant bugs.  So just go with GStreamer in KDE 4, please.  Assuming 
it can be made portable, that is!

- -- 
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