CSL Motivation

[Kai Vehmanen]

On Thu, 27 Feb 2003, Tim Jansen wrote:

>> 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.
[...]
> This problem is impossible to solve. But CSL makes sure that you can use every 
> regular KDE application with every sound backend. So if you are using a JACK 
> app, you need to use JACK as sound server. I guess there is nothing on the 
> world that can solve this problem, unless every backend/server supports every 
> API.

... unless you promote a limited set of configurations:

1. aRts as it is now
2. aRts + JACK
    - aRts apps continue to work (via aRts_JACK; this needs to be implemented)
    - gstreamer apps work (via its JACK support)
    - native ALSA PCM apps work (via ALSA's JACK-plugin)

... (1) is for portability and network transparency and (2) for getting
max out of Linux audio apps. Once JACK and ALSA are available for more
platforms, these platforms could then also benefit from (2). But my point
is that you'd have to have a standard KDE way of selecting between (1) and
(2), or otherwise the KDE users won't find this option and the current
fragmentation of user and developer base will continue.

Alternatively you could select 'aRts + ALSA+dmix' as the the mode (2).  
We could still manage to run JACK at the same time, but then KDE wouldn't
know about it. Whether this is good or bad, that depends on you.

But, but... it does look quite complicated. A CSL lib that could sense
(during runtime), which backend is available, might indeed still make
sense.  This is especially true for avoiding starting any servers if user
just wants simple output. On jack-devel there have been some discussion
about adding similar functionality to libjack (i.e. the first app will
become the server => optimize the single-app case). This has the benefit
of avoiding the huge amounts of potential problems that are associated
with running separate servers.

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