Some ideas for the aRts-replacement
neil at hakubi.us
Mon Feb 23 17:55:57 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
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 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