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
