Some ideas for the aRts-replacement (was: aRts needs to be replaced (was Re: Disabling aRts in knotify))
neil at hakubi.us
Thu Feb 19 23:31:16 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
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 hakubi.us
"It's snowing, it's snowing! God, I hate this weather."
They Might Be Giants, __New York City__
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the kde-multimedia