aRts vs JACK

[Stefan Westerfeld]

   Hi!

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_
dependancies.

* 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 contributors/users.

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.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-