On Thu, 27 Feb 2003, Stefan Westerfeld wrote: [ Paul's msg I forwarded ] And just to give you kde-multimedia people a view of the current status, take a look at: http://jackit.sourceforge.net/apps/ JACK has been really been quite a success. The ability to run multiple apps and route audio freely (and easily thanks to qjackconnect!) between them, with reliable low-latency is something that has attracted a lot of developers and users to JACK. A few screenshots (sorry about the eca-emphasis :))...: http://eca.cx/screenshots/jack_and_ecamegapedal_under_heavy_load-20021102.p… http://eca.cx/screenshots/qjackconnect_ecamegapedal_ecasignalview_jack-2002… What I'm personally most impressed and proud about is that we've been able to get developers from different (some directly competing) projects to work together on this. Although linux-audio-dev is an active communicty, actual code-level sharing so far has not been common. It would be great if KDE (and GNOME) users could join the fun without having to completely abandon desktop multimedia while doing this. The next step would be to close the bridge between kde-multimedia and linux-audio-dev... ;) Yup, I guess it wouldn't be too big of a task to adapt (for instance) the ALSA's JACK PCM-plugin for the CSL API. Hopefully someone will do this. Do you have any code in place that handles the backend detection for CSL? -- http://www.eca.cx Audio software for Linux!

On Thu, Feb 27, 2003 at 05:21:10PM +0100, Stefan Westerfeld wrote: Well, AFAIK the current CSL implementation is rather poor. There is aRts and OSS output only (not even ALSA!) and no pluginable interface yet. The sound server has to support other sound servers. A bit sane, isn't it? -- jozef kosoru

The point is that PortAudio follows the same basic abstraction that the audio APIs on the overwhelmingly dominant platforms for audio software development follow (callback-driven). Those APIs have emerged from years of practical experience writing serious audio applications, and I strongly believe (as you know) that they should be taken very seriously. The fact that a couple of early linux hackers felt that the open/read/write/close/ioctl model was the right thing seems to me of much less significance than the number of working, useful, sophisticated software that have been built around a set of abstractions that are more or less identical to the ones PortAudio provides. that depends on where you started from. if you started from ASIO, it won't be hard. if your app started as a VSTi, it won't. but sure, if you started as your typical linux audio app that reads a stereo file from the disk and shoves it into the audio interface, it will be fairly easy to use CSL and a bit harder to use PortAudio. this porting thing bothers me. we have only a handful of really great apps for audio under linux right now (though we have lots of rather interesting ones) and most of them already can use JACK. i would much rather see people forced (just like apple have done) to work with the "correct" abstraction than continue with multiple wrappers and multiple different abstractions as we move into a period where i hope to see an explosion in linux audio applications. well, there are at least two sets of evidence to consider there. i think there is plenty of evidence in the world of windows that a large amount of interesting audio software works with the ASIO and DirectX models (which are semantically similar, if syntactically worlds apart). its not limited to audio synthesis. but at the same time, its worth noting that "most" apps on windows that emit audio for some reason (i.e the ones that are not actually audio applications) do not use ASIO or DirectX. so there is evidence to support the idea that at least a couple of abstractions are necessary. in contrast, CoreAudio offers only 1 abstraction model as i understand it. so apple at least appear to have been willing to bet that all software can use a single model. i don't think its about liking it so much as the fact that it does some things that are extremely important to many of us and that nothing else can do. well, i am *really* not trying to be argumentative just for the sake of it, but ... the reason not to is that CSL doesn't offer any new functionality. its just another wrapper, and we already at least one of them, with some evidence that its capable of supporting all apps. since JACK has no desire to be a general purpose API for all apps, this would be more appropriate than the other way around, i think. there is no reason to run a JACK system that does audio i/o via a sound server - it just isn't going to work with the performance promises that JACK is supposed to provide. i think that the fundamental problem here is the division between: * the kinds of apps that emerge from the repeated questions on gtk-list (and i'm sure the KDE equivalent): "what's the best way to play a sound?" * "serious" audio applications (and, i suppose, video apps too) CSL seems to be about providing something to the first group that PortAudio *could* provide, even though it may not be the best or easiest method (although it might be the most appropriate). but i really don't see how it offers anything to the second group that want features (and to some extent, *lack* of features) beyond those CSL or even PortAudio provide. i see it this way because CSL doesn't appear to me to have emerged from efforts of audio developers. its come mostly from the desktop world as way to meet the need for a "cross-desktop" way to say "you've got mail" or play the KDE startup theme, and other "singular" audio events. as i said above, the windows experience suggests that it may be useful, perhaps even necessary, to have two different abstractions to support these two rather different classes of applications. but the jury is out on that. --p