30 Jul
2005
30 Jul
'05
5:10 p.m.
Hi ce and others...
2005/7/29, Christoph Eckert <ce(a)christeck.de>de>:
Typical kde-game has beeps and short bings as sounds, not a full
soundenvironment.
And it certainly doesn't need realtime.
Every other game uses gl or sdl and the needed soundsystem...
Seems to me in my limited foundational understanding of all this, and with
ALL due respect, that the point has been missed...or rather...there are
many points being made without recognizing the synergies.
Your outline of what KDE will or will not do is ok with me. If it doesnt
work great for me....I have options...I use another window manager or
desktop! There are quite a few to choose from now...but what I don't
understand is this; one of the underlying themes in this DL is the
attraction of Linux audio systems to Windows converts. To make that
easier, it obviously is a requirement to simplifiy som things. It would
seem to me the KDE (and don't get me wrong here...I love KDE!) Desktop has
become quite advanced in the 4 yrs I have used it....It used to have no
clue what file I clicked on in say...Konqueror! It has many memory sucking
background "services" running to improve it's intuitiveness...why is audio
and for example, the point Davis made (and I believe he demonstrated clear
Un bias in his comments for and against one of his own developments) with
regard to Coreaudio or something with as much versitility, NOT a
consideration when it would appear to be directly in line with the other
optimizations KDE has included in their wonderful Desktop?
Not a flame in anyway or intended to agravate; I DO love KDE!!! But the
limits that seem to apply in thinking here as to what gets in or not in
development almost sounds M$ esque on some levels...
Just food for thought.
R~
Please
say good-bye to the thought of jack as the
soundserver for everything. Jack is for professional raw
datastreams with very little latency. For the typical
desktop-app/game its irrelevant how much latency there is
(if its not 2 secs)
sorry, wrong. What about the gamers? What about keeping audio
and video in sync?
1: This will be done by the underlying soundsystem, not by kde.
2: Can Jack do video?
What about the (still missing) Garage Band
clone on the KDE desktop?
This will use jack directly...
All of these will need low latency, and
especially Garage Band
is a product for Amateur use.
But you don't need low latency for the "You got mail"-sound or the bing
of kopete. And therefor it is not the solution to struggle with jack.
And jack can't do decoding, which the kde apps need!
We're on free software, and there's no
need (at least from a
technical POV) to deny desktop users the use of low latency
audio and video. We're at an important "point of no return":
We can make the right decision *now* or the audio and video
struggle will continue.
We don't make a decision, apart from beeing open which soundsystem the
future brings. We from kde don't want to focus on one system and
realize its not maintained two years later... bad experience from the
past...
just face it: jack is _very_ good for professional and semi-pro usage in
audio. But it is not a full multimedia-system (audio _and_ video) and it
doesn't decode any files. These are the things kde needs!
What keeps KDE from switching to gstreamer directly: binary
compatibility. gstreamer has changed its api in a bic way about three
times the last two years, kde ensures bc for the full kde3 and again for
the full kde4-lifetime.
My last comment: You from LA[UD] won't change KDE's decision, which
already has been made... towards a layer between kde and the
soundsystem to use to be able to choose the soundsystem during
runtime...
And Linux doesn't have to choose _the_ one soundsystem to rule them all.
The big advantage of Linux is exchangability.