aRts vs JACK

[Jozef Kosoru]

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] <zyzstar at uid0.sk>