[clug] aRts needed these days?

[Chris Smart]

On Thursday 27 July 2006 10:27, you wrote:
> It serves a slightly different purpose - aRts is an abstraction layer (for
> portability, KDE runs on OS other than Linux, apparently). Well, arts is
> meant to be an abstraction layer. Mostly it is an unmaintained mess, and
> its main purpose is to give KDE developers an example to point to whenever
> someone wants to introduce a glib dependency into KDE.
:) Thanks for the info Brad. When there was only OSS, aRts was a necessity 
else sound was very poor under KDE, like trying to play sound files at the 
same time (as far as I remember). But since alsa provides excellent support I 
haven't found the need for aRts. Kaffeine, amarok, etc use xine or gstreamer 
engines instead of aRts and all the sound works as it should. So aRts just 
seems to sit there and not be used / and or create a few problems along the 
way ;)

> Interestingly, the goal of arts was to support both gnome and kde.
I'm sure it probably does :) Kororaa will have a common set of USE options 
across the KDE and Gnome versions, which means if I have arts set in then 
Gnome users will get it too and any application that supports aRts will be 
built against it. It's not a major problem, but just not necessary for Gnome 
users I guess. On the other hand it might not hurt to have the option there 
to use aRts if people want to, rather than xine or gstreamer..
>
> BTW: for KDE4, KDE will have a simple abstraction API (Phonon) that uses
> backends like NMM, GStreamer or similar.
Ahh ok, good stuff. Looking forward to KDE4 :D

So in the end, do you think is it worth including? ;)

Ta.
-c