CSL Motivation

[Kai Vehmanen]

On Wed, 26 Feb 2003, Tim Jansen wrote:

> What exactly is the problem? The intention of CSL is that the usual desktop 
> applications do not depend on a output system. If someone writes an audio app 
> that uses JACK or ALSA directly, why can't it be used together with the CSL 
> apps?

Ok, correct if I'm wrong, but isn't it so that if I - as your average KDE
user - want to use a JACK app, I need to disable aRts completely, do the
reconfiguration outside KDE configuration tools (which I happen to know
the best), and once I succeed, my KDE audio apps won't work anymore. Now
I'm first to admit that this is not an easy problem to solve, but it's
also true that you can't use the same API for all apps... some will be
satisfied with CSL, while some need JACK, or even ALSA.

>> 1) A front-end API that is part of the KDE devel API
> GStreamer is not a front-end API. It can use aRts, CSL, Portaudio or ALSA/OSS. 
> (CSL and Portaudio sinks would have to be written first though).

Front-end API was not perhaps the best term... what I meant was 
the kde/gnome application interface, the API app developers will use. 
As this is just the thing gstreamer was designed for, that puts it 
firmly into the (1) category. 

In the second category (backend servers) I had software that can a) manage 
multiple clients, and b) communicate with the audio hardware (either 
directly or via other components).

--
 http://www.eca.cx
 Audio software for Linux!