i810 audio fixes 1/2

[Paul Davis]

>The issues with arts and esd are that by their very design they are unsuitable
>for professional audio use.  Its easier to add things to the lower latency 
>design of jack than it is to improve the latency of blocking io apps like 
>arts and esd.

to reinforce Chris' point: *no* significant linux musical application except
Beast has any capability to use either arts, and only a few still use
the OSS API, which theoretically would allow for esd (even if it
doesn't work in practice).

if the freedesktop people have any intent of avoiding a split between
the music world and the "desktop beep" world, JACK is the only viable
sound server. if they don't care about such a split, then neither do
most of us in the music/pro-audio world.

the ALSA API allows applications to be written so that they are
neutral about the kind of device they talk to; its possible to move
audio data to JACK, to a dmix device, a hw device and god knows what
else via alsa-lib. 

IMHO, the choices in front of sane audio developers are:

    (1) if sample-synchronous and/or low latency behaviour and/or
         inter-app routing are important, use the JACK API. no other
         Linux API will provide these features and no other API is
         even close to offering them.

    (2) otherwise use either 
           (a) PortAudio if platform portability matters
	   (b) alsa-lib if its really just a linux program.

The most important issue is designing applications around a callback
model wherever possible. This is still an issue with alsa-lib, and
remains an issue with MAS and some other network protocols. There are
examples of bridging the unix-derived block-on-{read,write} model with
the callback one, but although they work, they are really a band-aid
that covers a deeper issue.

Some applications of audio i/o really not require sample-synchronous
or low latency behaviour, and are much easier to write using the
unix-derived block-on-{read,write} model. 

It has been my intent to take these matters up with freedesktop.org,
particular since two of its key members, Keith Packard and Jim Gettys,
were on the panel that awarded JACK its Open Source Merit Award in
January. 

>What high level functionality do you speak of besides automatic sample rate 
>conversion?  I'd imagine network transparency could even be bolted onto jack 
>if necessary.

indeed. JACK is network protocol neutral. jackd itself does not (and
will not) implement any network protocols (it doesn't even implement
ALSA or OSS - thats handled by a special client), but it would be
relatively easy to code an MAS client, or a low-level ethernet
(Cobranet) client, or a client that uses 1394 as a transport protocol,
or whatever. Just like JACK's other features, this kind of
interconnectivity is *designed* to be provided by clients, seamlessly,
not by the server.

--p (but you can call me JACK)