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@xxxxxxx). 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
