This is an explanantion from kde-multimedia(a)kde.org as
to just
why it would seem to be a problem...
The design is basically flawed for desktop audio since it
delegates real-time low-latency work loads through unix
pipes to the audio applications. You cannot expect all
audio applications to run real-time and you can not expect
users to apply custom patches that allow jack to hand out
real-time privileges.
as Lee Revell points out, this is totally bogus: its what CoreAudio
does, and its precisely why 2.6.{11,12} or something has the rlimits
change, and now PAM too. KDE either needs to explain why CoreAudio
doesn't work properly or stop using this explanation of why JACK is a
bad idea for desktop audio (not that there aren't other reasons).
I've been
discussing this with Scott Wheeler on thios years
Linuxtag. Similar to Linus Torvalds, the KDE team simply
waits what will mature most until the day a decision must be
made.
If that means "least problematic" then sure, if "most mature"
also means most widely deployed for any audio work that matters
then the choice probably should be JACK.
You are all forgetting that JACK has a major, major problem: no
framework for varying sample rates. CoreAudio doesn't force this on
apps.
For this
reasons, it seems to be more probable that something
like gestreamer will be chosen, and gstreamer will then have
a JACK sink.
An extra complex layer on top of the one that really counts.
depends on where you are coming from. as a non-music/pro-audio app
author, its the layer KDE will put above "the sound system" that
matters. for the music/pro-audio app authors, JACK is the one that
matters. its not clear cut.
personally, the idea of generic apps that want to do audio using JACK
seems pretty dumb to me, but not without some merits.
KDE4 has the opportunity (maybe) of doing this. Once
another
subsytem gets into the SVN repository then JACK will never
become the default option. Right now, in mid 2005, there is a
small window of opportunity for JACK to become the default
sound server for one of the major linux desktop systems. If
this were to happen then we'd (linux) have half our future
desktops come by default with a world class professional audio
subsystem second to none. Hello Hollywood.
i think not. CoreAudio works as well as it does because of the right
control apple has over the h/w setup. we don't have that, and people
using windows on <their-chosen-h/w-setup> will continue to have xruns
and all kinds of wierd stuff in a significant fraction of cases.
Does anyone on this list use gstreamer to get
Rosegarden,
hydrogen, ardour and JAMin to work together ?
Does gstreamer allow kino and cinelerra to work together ?
gstreamer has *NOTHING* to do with inter-app audio. so many people seem
to forget this. it is *intra-app* framework for handles streaming data.
nothing more or less. most authors using gstreamer could probably care
less where their data ultimately exits their app.
i think that the real question is not JACK or not. its whether KDE is
willing to recognize what makes CoreAudio so superb, and assist with the
significant development work required to extend the capabilities of JACK
so that it could serve the same role on Linux. No other system available
at present comes close to offering CoreAudio-like functionality, and it
would be foolish to miss the chance to have similar functionality for
Linux.
--p