Subject: Re: [linux-audio-dev] Fwd: CSL Motivation (fwd)
From: Joshua Haberman (joshua_AT_reverberate.org)
Date: Tue Mar 04 2003 - 06:18:21 EET
The next version of PortAudio supports blocking read/write for host apis
that support it directly:
http://www.portaudio.com/docs/proposals/005-BlockingReadWriteInterface.html
In my opinion, CSL is redundant in the face of PortAudio; PortAudio is
more mature, both in interface and implementation (see
http://www.portaudio.com/docs/proposals/index.html for a record of the
design process that has gone into PortAudio v19). On the other hand,
neither CSL nor PortAudio is appropriate for applications in a desktop
framework (like KDE or GNOME) that simply want to play a "ding."
Here is my ideal for the future of Linux audio:
1 Most audio applications are written to PortAudio, which supports OSS,
ALSA, and JACK (the latter as long as the app uses the callback
model). These are applications that are audio-intensive, as opposed
to applications that have more simple needs like playing short wav
files.
2 For a sound server, JACK becomes ubiquitous, after undergoing more
revision that allows it to better support high-latency,
low-performance situations. The desktop projects adopt it as their
sound server.
2 (alternatively) JACK remains confined to people who have a need for
inter-application exchange of audio data, and another sound server
(perhaps MAS) becomes standard for consumer desktops.
3 KDE and GNOME implement high-level sound-playing functions that use
Gstreamer internally. This way they read every format and support
every output engine automatically.
Paul: (2) above may make you nervous, but look at it this way. You have
said in the past that every Mac OS X application is capable of
interchanging audio data out of the box, thanks to CoreAudio. The flip
side of that coin is that CoreAudio was written to be usable by every
application ever written for Mac OS X. Yes, JACK is designed for
serious audio work (as is CoreAudio) but that's no reason why it can't
be appropriate for other situations also.
The only disadvantage I see in the above scheme is that there is some
duplication of code between PortAudio and gstreamer. But this seems
irreconcilable; GStreamer isn't useful for Multimedia-editing
applications (unless they were built from the ground up to use it), and
I doubt GStreamer will ever use PortAudio for audio output.
Josh
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 06:22:43 EET