[linux-audio-user] New Sound Subsystem Needed For Qt4/KDE4

[Paul Davis]

> This is an explanantion from kde-multimedia at 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