Stefan Westerfeld, the author of arts, the media fromework for KDE 2.x and KDE 3.x, has written a nice piece on why many of the technical assumptions that he held while developing that software do not hold true. He then shares his insight into the future of media in KDE 4.0 and the free desktop world.
Stefan Westerfeld on artsd
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I agree with Stefan is the sense that one should not try to reinvent the wheel, however there is at least another option, rely on the Apache Portable Runtime libraries. It could have opened up some interesting WebDAV options.
Anyway, hindsight is 20/20. User needs evolve and the environment evolves. It’s impossible to anticipate everything even if you planned for years. Sometimes, “good enough” delivered now is better than “perfect” delivered next decade (especially if you can’t predict how sound APIs will evolve in 10 years). Arts was definitely good enough and I believe it’s limitations gave other sound systems insight into what works and what doesn’t so that they could start fresh.
Thanks Stefan. I don’t use KDE, but arts’ existence and reasonably good quality forced GNOME to handle sound better.
An open source developer stepping back and admitting to design mistakes. There are a number of them in the design of MCOP which leads to an undesirable tradeoff between latency and CPU usage. In the Linux world ALSA and JACK are now more or less on par with their pro audio counterparts, CoreAudio and ReWire. Unfortunately there’s too much fragmentation for these to take over as a definitive standard, and we’ll be left with the awful curmudgeon of OSS, ALSA, esd, ARTS/MCOP, JACK, and a dozen other tools and standards which will all continue to be used and therefore require support.
Major kudos to Stefan for admitting his past mistakes. Unfortunately Linux audio will sadly remain a mess for quite a time to come…
KDE developers are exploring their options for along time now and apparently KDE4 might use gstreamer:
http://lists.kde.org/?l=kde-multimedia&m=110191508516329&w=2
(kde-multimedia mailinglist)
Gstreamer supports ALSA, OSS, esd, JACK and even artsd. The esd replacement Polypaudio which Westerveld mentions has a gstreamer-plugin too. So users mixing all kinds of media applications might have a lot less tweaking to do in the future, using one media framework.
I am more optimistic. My expectations are that JACK and ALSA will be the choice for all pro audio tools and gstreamer will be the standard for desktop media.
I see the light here. KDE gets infected with som G* packages and GNOME with som K* packages and freedesktop.org unites the core interfaces…
It might kill some superstitious barriers. I know I’ve been reluctant to mix KDE and GNOME apps.
+1
And btw GStreamer is uber cool
I do not see a reason why I should not run a GNOME app while having a KDE desktop running. Are there any problems I don’t know of?
The only real issue is the extra memory usage for loading two sets of libraries.
Going the other way isn’t as nice, because there is no way to make a qt app look like a native gtk one, and I personally think the kde apps have a tendency to look very tacky compared to Gnome ones…
See the FAQ at gstreamer.net. KDE teams are free to make their GStreamer GUI work in QT as long as they comform to the APIs.
I suppose most people see it that way because of the G. We wouldn’t see that fuss if it was, dunno, Hstreamer or Sstreamer…
KDE developers are exploring their options for along time now and apparently KDE4 might use gstreamer… Gstreamer supports ALSA, OSS, esd, JACK and even artsd.
KDE 4 will not include GStreamer. The plan is to have a KDE multimedia framework with the option for multiple back-ends – GStreamer being one of them. Of course there may be a defult, there may not. That’s something for KDE 4.
The problem with GStreamer is its C-based architecture. Someone wants to buy these guys a good object-oriented C++ book. The bindings for KDE are already falling behind to the point where developers are not using them and using the C API directly. If this is happening now, what happens in the run up to a KDE release and what does that say about the long-term maintainability of this approach? We’ve already had this with arts.
I suppose most people see it that way because of the G. We wouldn’t see that fuss if it was, dunno, Hstreamer or Sstreamer…
What would happen if it was KStreamer? Now there’s a thought, and I bet I can guess what the answer would be……
What would happen if it was KStreamer? Now there’s a thought, and I bet I can guess what the answer would be……
That’s why I didn’t mentioned it.
The idea of gstreamer is nice, but I’ve never gotten it to work properly. Everything is delayed, as if it has to fill an internal buffer before performing any action. EXTREMELY annoying.
If I hit Play or Pause or anything in a gstreamer based player it takes about half a second for anything to happen while XMMS, which uses ALSA/OSS directly, is instant.
Anyone else run into this problem? Maybe it’s just a setting somewhere… Driving me nuts.
It might be worth running gstreamer-properties and checking the default output sink. I tend to explicitly choose ALSA, but I’m sure there are some setups out there which are using something dreadful like esd (which would /definitely/ cause high latency/delays).
I’m quite happy with my sound on Linux produces by the ADI1980 chipset.