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

[Christoph Eckert]

Hi all,


as Scott Wheeler isn't a subscriber to this list he was not 
allowed to send it to the list directly. Instead, I'll 
forward it for him:


======



> > Apparently aRts could be removed from KDE4 CVS HEAD RSN. 
As
> > far as I know there is no decision on an official
> > replacement yet.

I haven't seen the rest of this discussion, but it seems out 
of place to me.  
Pretty much any discussion on the future of KDE multimedia 
should happen on 
the KDE multimedia list (kde-multimedia at kde.org).  Discussions 
anywhere else 
-- for better or worse -- are likely to be fruitless.

> > I have no say in the matter but I would
> > like to see something like qjackctl ported to KDE4 and
> > usable from within kcontrol, basically, Jack embedded into
> > the system from the ground up.
>
> This will not happen.

Correct.

> > My general question, to those who know far more than me, 
is
> > just what would be the ideal sound subsystem for KDE in
> > 2006 seeing there is a clean slate and an opportunity to
> > get it right from the get go ?
>
> 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.

Well, it's a step back from that in a sense.  We're kind of 
punting on this 
one for KDE 4.  Matthias Kretz has been working on a generic 
API for 
"typical" user applications (think players and maybe some 
basic recording) 
that will load plugins which implement the API.  GStreamer 
will certainly be 
one of those and may be the default, but also as was noted 
GStreamer isn't a 
soundserver or collection of drivers.  It's a framework for 
creating 
multimedia pipelines that handle demuxing, decoding, 
processing and then dump 
them somewhere -- there are "sinks" for various audio and 
video systems.  The 
same goes for NMM, which is another likely candidate for a 
plugin in 
mentioned API.

> I guess JACK will *not* be an option for the KDE team 
because
> it's not configured on every distro per default and JACK
> isn't platform independent.

Actually it won't be an option because it's a soundserver.  
We're not looking 
for a soundserver, we're looking for a multimedia framework.  
How the sound 
gets to the soundcard/soundserver is up to that framework.

> For this reasons, it seems to be more probable that 
something
> like gestreamer will be chosen, and gstreamer will then have
> a JACK sink.
>
> For audio stuff, I dislike it, I'd like to see JACK beconimg 
a
> standard desktop soundserver.
>
> But gstreamer has some further advantages: It's not specific
> for audio only. For example (if I got it right) it can also
> provide a video stream from one device to multiple
> applications, so it also solves one problem JACK solved for
> audio for video applications.
>
> I personally would be happy if JACK would be chosen, so we 
had
> *one* *tru* solution for desktop as well as for professional
> use, comparable to coreaudio on Mac OS X. But I fear that
> there will be another decision and this will again delay
> finding *the* *true* solution :( .

Just to repeat again -- KDE most likely won't be choosing a 
soundserver.  At 
the very most we may have some recommended defaults.  I said 
it above, but 
it's worth repeating -- Jack is a soundserver; the problems 
that Jack solves 
aren't really all that relevant to KDE's multimedia decisions 
-- they're 
orthogonal to them.

-Scott
        
-- 
Three words: you have no clue
-Slashdot