aRts vs JACK
neil at qualityassistant.com
Mon Feb 24 15:56:27 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Monday February 24, 2003 07:15, Stefan Westerfeld wrote:
> On Mon, Feb 24, 2003 at 06:29:39AM -0800, Neil Stevens wrote:
> > On Monday February 24, 2003 05:17, Stefan Westerfeld wrote:
> > > Adding CSL support to KDE right now seems to me the right thing to
> > > do. It does not disturb people using aRts (because things will
> > > continue to function exactly as they do now), but it helps people
> > > not using aRts. And doesn't cost much to do it.
> > That's fine, add CSL as an add-on. But as long as CSL is glib-tied,
> > it's not the answer to KDE's needs.
> There is still some confusion, I think.
> * CSL = common sound layer
> Is a simple plain C API. You give it an audio stream. It plays it. You
> ask it for an audio stream. It gives it to you. It does not have _any_
> * BSE/SFK = bedevilled sound engine / synthesis fusion kit
> Is an aRts-like synthesis and effects thing using glib, currently
> exclusively used in BEAST. I do not recommend adding it to KDE at this
> point in time. If MCOP/SFI can be merged at some point in time remains
> to be seen. This however would most certainly mean a glib dependancy for
> the merged result.
> If this is inacceptable for aRts for some reason (it may for whatever
> reason not be my right to decide what is right for aRts and what not,
> even although I have written a lot of code in aRts), then aRts will have
> to remain without glib dependancy, and presumably without sane C
> language binding.
> Strategically however deciding against glib for aRts in the future this
> means that if you're a C coder (and there are a lot of these out there),
> aRts will not be for you, which means loosing potential
Well, I'm already seeing complaints about just a glib *dependency*, but
that's not what I mean. I'll try to be more clear: KDE apps shoudln't
have to use a glib API, and KDE developers shoudln't have to use glib to
write new extensions to the KDE-chosen media system.
> If you look at Arts::Thread, Arts::Dispatcher, arts/gsl/gslglib* you
> will see that aRts is duplicating quite some glib functionality even
> today. At some point however, using glib, or alternatively, using Qt
> might be cheaper than duplicating everything.
> Currently I however refuse to consider depending aRts on a GUI toolkit,
> whereas glib would only be a moderately sized C portability library. In
> fact, I would even think that depending Qt on glib would be a very wise
> decision interoperability wise, because it would open a much easier path
> towards in-process coexistence of GNOME and KDE code snippets.
In theory, glib is not a GUI toolkit, no. But in practice, glib is a
foundation of the GNOME system, and is not used in KDE. This puts KDE
developers at a severe disadvantage if the KDE media system makes you use
But maybe I am confused. I hope you'll set me straight. Coudl you put up
a webpage explaining just what CSL is? All I can find on the aRts page
are announcements of CSL, and a few slides saying GNOME should use aRts.
Neil Stevens - neil at qualityassistant.com
"Distinctions by race are so evil, so arbitrary and insidious that a
state bound to defend the equal protection of the laws must not allow
them in any public sphere." -- Thurgood Marshall
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-multimedia