From kde-multimedia Mon Feb 24 14:37:53 2003 From: Jozef Kosoru Date: Mon, 24 Feb 2003 14:37:53 +0000 To: kde-multimedia Subject: Re: aRts vs JACK X-MARC-Message: https://marc.info/?l=kde-multimedia&m=104609741017348 On Mon, Feb 24, 2003 at 02:06:09PM +0100, Stefan Westerfeld wrote: > On Mon, Feb 24, 2003 at 10:34:27AM +0100, Jozef Kosoru wrote: > > On Sat, Feb 22, 2003 at 11:09:24PM +0100, Stefan Westerfeld wrote: > > > > Is CSL going to be the real future? > > > > > > Write a CSL driver for JACK, if you ask me. Thats what I recommend w.r.t. MAS > > > as well. > > > > Well, I've looked a bit at the ALSA JACK pcm_plugin and it seems to be the > > brilliant solution for the 'aRts vs JACK' problem. It allows > > non-realtime clients to use JACK as a backend. This is far better and > > more complex solution than JACK output plugin for aRts or CLS layer, > > because it covers OSS apps and ALSA apps as well. > > I am not entierly convinced of this, because this doesn't solve the > interoperability problem for systems that ALSA doesn't run under. The very > idea of CSL is to get rid of the sound portability problem once and for all > on all (unixoid) platforms. > > Thus, if CSL supports aRts and JACK, and for instance xmms supports CSL, then > xmms will be able to use whatever is appropriate on all platforms that KDE is > running on. > > The same is valid for MAS, JACK, aRts, GStreamer or any other "meta- > application". As long as we add CSL support to each of them, then all of > these will interoperate in any combination with eachother, transparent to the > user. > > Of course you may argue that porting and deploying ALSA on all platforms will > do the same. However, I think that while "not supporting anything but CSL" > could be made a feasible option for most sound applications within the next > months, "not supporting anything but ALSA" is far from this. Yes, I fully agree that the status of audio API on Linux/Unix is like a zoo. There are at least five working (and used) sound servers, two kernel level drivers on Linux and some others on other Unix variants. Indisputable it's a great mess and from this point of view; CLS is a good thing. But: 1) No one can predict wheather this new API will be accepted by the UNIX/Linux communty. After all - it's just another API and we have a plenty of them already now. 2) CLS adds one layer to the application<->sound_card chain. For the high-end time critical audio apps this would be a problem. 3) CLS also cannot support all different types of audio API paradigms (read-write API vs callback-driven API). For example: a good JACK client must fulfil a certain criteria to retain a realtime low-latency approach. Its 'process' callback method should not lock mutexes or call other operations which may cause a contex switch. These are very specific requirements which 99% audio apps does not meet. There won't be a simple way to port applications to the JACK via CLS api. My opinion is that big 'make-it-all' projects like aRts, MAS, GStreamer do not have a good level of flexibility and which is even worse; they force users to use a certain set of applications. Thus the standardization is really needed but CLS sounds me like a too idealistic solutions. Do you really believe that all audio applications out there will start using CLS within a few next months? And what about the old unmaintained (but still used) applications (commercial games etc.)? With all these things in mind - "not supporting anything but ALSA" strikes me as a much more realistic option. -- jozef kosoru [zyzstar] _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia