> Hi ce and others...
>
> 2005/7/29, Christoph Eckert <ce@email-addr-hidden>:
>> > 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?
>
> 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...
>
>> 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.
>
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~
Received on Sun Jul 31 00:15:26 2005
This archive was generated by hypermail 2.1.8 : Sun Jul 31 2005 - 00:15:26 EEST