27 Feb
2003
27 Feb
'03
12:29 p.m.
Hi!
On Tue, Feb 25, 2003 at 07:48:11PM +0200, Kai Vehmanen wrote:
Date: Tue, 25 Feb 2003 12:20:22 -0500
From: Paul Davis <paul(a)linuxaudiosystems.com>
Reply-To: linux-audio-dev(a)music.columbia.edu
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Fwd: CSL Motivation
CSL also "exists".
There are discussions on kde-multimedia about
the future of Linux/Unix multimedia (especially sound).
This is one of the most interesting messages.
CSL is proposed primarily as a wrapper layer around existing APIs. as
such, it seems to me to have no particular merits over PortAudio,
which has the distinct advantages of (1) existing (2) working on many platforms already and
You're right about that one: CSL is not as complete as PortAudio w.r.t to
portability.
(3) using well-developed abstractions.
I do not believe that something is ever a "well-developed abstraction" by
itself. Something is always a "well-developed abstraction" from something,
designed to achieve a certain purpose. From the PortAudio homepage:
| PortAudio is intended to promote the exchange of audio synthesis software
| between developers on different platforms, and was recently selected as the
| audio component of a larger PortMusic project that includes MIDI and sound
| file support.
This clearly states the purpose: if you want to write audio synthesis software,
then you should use PortAudio. Then, I assume, the abstraction is well-
developed. However, it does not state:
"... is intended to play sound samples with sound servers easily. Or: ... is
intended to port existing applications easily. Or: ... is intended to let
the application choose its programming model freely."
No. PortAudio makes a lot of choices for the software developer, and thus
provides an easy abstraction. This will mean, however, that actually porting
software to PortAudio will probably be hard (compared to CSL), whereas
writing new software for PortAudio might be convenient, _if_ the software
falls in the scope of what the abstraction was made for.
CSL was
written as if PortAudio doesn't exist. I don't know if this a NIH
attitude, or something else, but I see little reason not use consider
PortAudio as *the* CSL, and by corollary, little reason to develop Yet
Another Wrapper API.
Well, I gave you some. The paper gives some more. Basically, CSL is intended
for porting _most_ free software, whereas PortAudio is intended for portable
synthesis software.
I think PortAudio would benefit in _supporting_ CSL, rather than aRts for
instance, because CSL is more generic ; once new sound servers (like MAS)
come up, you need not patch PortAudio all the time, but just one place: a
CSL driver. The same is valid for other meta-frameworks like SDL.
the only reason i was happy writing JACK was
precisely because its not another wrapper API - it specifically
removes 90% of the API present in ALSA, OSS and other similar HAL-type
APIs.
I am glad you did write JACK, although back then I thought it was just another
try to redo aRts (and we had some heated discussions back then), because some
people seem to like it. If some people will like CSL, why not?
If you added CSL support to JACK right now, you would never need to bother
with any of the "sound server guys" like me again, because you could always
say: "support CSL in your sound server thing, and then JACK will support your
sound server".
On the other hand, if you added JACK support to CSL, you could also mix the
output of all of these "sound servers" into JACK, without endangering your
latency properties.
Cu... Stefan
--
-* Stefan Westerfeld, stefan(a)space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-