JACK
*isn't* intended for general use, and i get tired of suggestions
that it should be. there are lots of people working on solutions for
"general use". JACK is intended for people who are serious about
audio.
I'd like to add that not all JACK developers are as strict about this as
Paul ;), but it's true that something more concrete than
actually, i'm not really as strict as i sometimes sound.
yes, i think it would be great if JACK can eventually serve as a
general purpose sound server (though an even better intermediate goal
would be get to all apps to use a callback model). but i don't want to
get distracted by that goal when there are still some very difficult
issues standing in the way of 100% reliable operation at low latency
settings. creating something that is a credible replacement for arts
or esd etc. is a very different exercise than what we are focused on
right now.
And I think you can run JACK using pretty much any
ALSA-supported
soundcard. It's just that we cannot guarantee good performance or flawless
operation in these cases. These cards will also cause problems to other
applications. It's just that JACK makes these problems much more explicit.
one set of problems arise with consumer interfaces that don't keep
their capture and playback streams in sync with each other. another
set of problems comes from thos interfaces that don't allow mmap, but
there are almost none of those in current production. another set of
problems arise with cards that have unusual buffer size/division
constraints. other than that, there's nothing about the way JACK uses
ALSA that stops it from working (as Kai said) on pretty much any ALSA
supported soundcard. almost any audio interface that someone who is
"into audio" would use work excellently with JACK (and, not
coincidentally, with ASIO).
and guess what? if there is, you can get the source code and you can
fix it (or reimplement the ALSA driver/client if its basic design is a
problem).
--p