From:	 Paul Davis <pbd@Op.Net>
To:	 letters@lwn.net
Subject: Serious inaccuracies in JACK article
Date:	 Wed, 13 Feb 2002 23:14:54 -0500
Cc:	 jackit-devel@lists.sourceforge.net

Dear LWN,

as a lead developer for JACK, it was a pleasure to see our project
mentioned. Alas, the piece contained some serious
inaccuracies. Specifically:

>"Jack uses the ALSA driver for it's default audio i/o. Applications
>that work with ALSA should plug into jack with no modifications,
>assuming they are correctly written. OSS applications may require a bit
>more work to run under Jack."

This isn't true. Neither ALSA nor OSS applications can just "plug into
JACK". JACK is a radically different kind of audio API compared to
ALSA or OSS, and applications need to be (re)designed the same way
they would be if there were using any of the proprietary audio plugin
systems common on Windows and MacOS. Our website tries to make this
clear:

   Your app must be callback-based. This means that you shouldn't
   block on writes or reads from a PCM device; rather, you should have
   your app be "driven" by a function that gets called at regular
   intervals. This is a design decision. Then, take a look at the
   simple client code, and do your interesting stuff inside the
   process() function.

   Note that code written for any callback API can generally be ported
   to any other callback API fairly easily. Code that is written
   around a "blocking I/O" model generally needs to completely
   redesigned to be used in any kind of callback API.

>"According to the Jack FAQ, Jack is an implementation of a LAAGA, a
>Linux Audio Application Glue API."

LAAGA was the initial name coined for the project that is now called
JACK. Its not a noun or a description of a class of APIs.

I think it important to stress that JACK was not written to satisfy
the same goals as existing Linux audio servers such as esd and
artsd. It is specifically aimed at situations where low latency is
required, where it is required that all clients of the server run with
perfect sample synchronous behaviour, and where routing audio data
between different applications is desirable. These goals are the
origin and constraints on JACK's design, and they explain why we
started a new project rather than try to work with the esd and artsd
teams.

We would really appreciate these corrections appearing in or close to
your article about our project.

regards,

Paul Davis <pbd@op.net>                                 Bala Cynwyd, PA, USA
Linux Audio Systems                                             610-667-4807
----------------------------------------------------------------------------
hybrid rather than pure; compromising rather than clean;
distorted rather than straightforward; ambiguous rather than
articulated; both-and rather than either-or; the difficult
unity of inclusion rather than the easy unity of exclusion.   Robert Venturi
----------------------------------------------------------------------------