Open for Business has an interesting and comprehensive interview with KDE core developer and multimedia guru Scott Wheeler of JuK and TagLib fame. He outlines the future of KDE’s multimedia efforts. Looks like things move away from aRts as sound server and multimedia framework to a very open minded best-of-breed strategy for KDE 4.0, with GStreamer being preferred at the moment.
KDE’s Scott Wheeler on KDE multimedia
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
aRts always annoyed me because it seems to take about a second to respond, which is very noticeable. Plus, KDE have opened themselves up to more opportunities, like using the native sound system of some other OS.
arts has served me well for quite some time now, even with all its limitations it is a nice piece of software and very well integrated with kde
i think gstreamer is getting there. i agree: kde should stay with arts for the 3.x series, then adopting a new engine could be the opportunity to gain in consistency with other desktop environments.
gstreamer means freedesktop, and that’s cool. i also hope more kde developers join fd.org core “decisional” team in the future
While KDE could certainly use an improved multimedia framework as part of the base libs to make things easier for developers, app-wise it’s doing enormously well already. amaroK (audio; great library functionality), JuK (audio; awesome tagging), KMPlayer (video; super-clean UI) and Kaffeine (video) are strong competition for the iTunes, Winamps and Windows Media Players of the world, IMHO.
And they don’t rely on arts, either. Note that both amaroK and JuK already support using GStreamer as backend, and KMplayer and Kaffeine are easy-to-use frontends for various engines/backends such as MPlayer, Xine, video4linux and even DVB. KMPlayer also works as a KPart component, meaning it can be comfortably used as a browser/preview plugin within Konqueror as well as other KDE applications.
There is definitely no lack of good multimedia apps for the KDE platform.
I, for my part, surely hope that KDE chooses to use Gstreamer for KDE 4.0. With a large number of very talented KDE hackers Gstreamer could be rapidly improved and possibly even fulfill the promise which it offers. I was, and am impressed by the philosophy behind Gstreamer. But Gstreamer has consistently failed to follow through on its potential. Firstly the Gstreamer folks have been so unwilling to soldify the Gstreamer API that other applications which wanted to use it as a basis have had to go back and forth on using it-it is a almost a crime for a project which has reached its size, for this length of time, to not have a stable API. Secondly I have been forced to use xine/mplayer backends for my multimedia time and again because Gstreamer is so unreliable.
If KDE was to choose Gstreamer we could count on having twice as many hackers working on it hammering out a stable API and ironing out the bugs. It is an amazing framework-and I would far prefer using it over xine/mplayer. I check out Gstreamer about every 3 months to see if it is up to snuff-it is getting better, slowly but surely.
I also hope that KDE embraces MAS. Although I do not know enough about MAS to compare it to other equivalent software it does seem incredibly powerful. I am also curious as to JACK plays into this whole multimedia framework. MAS is hosted by xorg, which is turn hosted by freedesktop.org which is also the home of Gstreamer. If everyone can agree we could end up with a MAS/Gstreamer mutlimedia framework for the entirety of the Linux desktop-rather than a DE specific solution-a very appealing future indeed.
Well, Gstreamer is only at version 0.8. I don’t know for certain, but perhaps they will declare the API stable at version 1.0? While I’m a Gnome person, I hope the egos at KDE don’t get in the way of adopting something on the other side of the fence. It’d be a real win for everyone.
“Firstly the Gstreamer folks have been so unwilling to soldify the Gstreamer API that other applications which wanted to use it as a basis have had to go back and forth on using it-it is a almost a crime for a project which has reached its size, for this length of time, to not have a stable API. ”
gstreamer is installable parellely and guarantees ABI compatibility within the particular series (both 0.6 and 0.8) which side steps not having a stable API. when its ready to have a API stability it will call be gstreamer 1.0 instead of 0.8.
“I also hope that KDE embraces MAS. ”
polypaudio seems to be a much better choice than MAS and it has already been semi officially accepted for gnome 2.10.
http://mail.gnome.org/archives/desktop-devel-list/
http://0pointer.de/lennart/projects/polypaudio/
Kaffeine isn’t just a video player, because the xine libraries arent’ just for video. I use Kaffeine for all my multimedia needs.
Unfortunately, the developer decided to completely ruin the interface with version .5, so I’m sticking with 0.4.3b for a while.
> I also hope that KDE embraces MAS.
Gstreamer will use MAS. Not KDE or GNOME.
”
Gstreamer will use MAS”
who said so?
gstreamer isn’t just for video either, sound-juicer (cd ripper) and rhythmbox (music player) both use it.
Well, Gstreamer is only at version 0.8. I don’t know for certain, but perhaps they will declare the API stable at version 1.0? While I’m a Gnome person, I hope the egos at KDE don’t get in the way of adopting something on the other side of the fence. It’d be a real win for everyone.
I don’t think Gstreamer is GNOME technology regardless of the “G”.
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/c…
But you are correct in that it would be nice if KDE adopts this fully.
I think Linux needs a unified backend for multimedia, although I do love Mplayer.
I wonder how the Mplayer or Xine teams perceive GStreamer?
Personally I hope that both kde and gnome choose the same thing. Right now it looks like gstreamer and polyaudio has the best bet so they have my support.
I am a bit worried about the idea of wrapping gstreamer in kde 4 so that multimedia frameworks can be swapped. A multimedia framework strikes me as a pretty complicated thing. Trying to create a generic interface for something the size and complexity of a multimedia framework seems to be asking for trouble. It seems to add another layer of complication that is not really needed.
Sure I can see them not wanting to put all of their eggs into the gstreamer basket, but I really do not think the ability to swap in something nmm is worth it. I am worried that the amount of time spent building and debugging this will see no real gain for the end user. I am worried that the subtle differences between the frameworks will prevent this system from stabilizing in a decent time frame. I am worried that the layer kde apps will see will end up catering to the different backend’s lowest common denominator effectively neutering the neat features of the possible frameworks.
Hopefully I am misunderstanding their plans or missing something.
I hope the egos at KDE don’t get in the way of adopting something on the other side of the fence.
Jay, KDE developers are known to be smart. KDE uses _a lot_ tecnologies that are not made by KDE developers.
I assume, that ‘other side of the fence’ refers to Gnome. I haven’t seen any signs of the fence among KDE developers. Some end users are another story, though.
KDE and Gnome developers co-operate in many projects, see freedesktop.org or libvw for example.
I know there is a bridge GStreamer -> Jack, but IMHO it’s better to have a direct Jack interface in addition to GStreamer (for working with pro audio apps such as Ardour and the likes).
While I’m a Gnome person, I hope the egos at KDE don’t get in the way of adopting something on the other side of the fence.
With regard to Gstreamer, it looks a bit as if it was the other way round: Some people want Gstreamer to be adopted in KDE to demonstrate that everyone is willing to cooperator with other projects. I do not know Gstreamer well, but I hope this reason will be a minor one if KDE decides on a particular multimedia framework. And I honestly think no one has to *demonstrate* cooperation, because there is already on many useful projects (e.g. those on freedesktop).
As for my personal opinion, I think NMM would be a very good choice. It has a quite good design IMHO, it approached a usable state in a rather short timeframe, so it (tends to) prove to be a developer friendly framework. It has committed developers behind it and the commercial world shows already interest in it, so professional backing could be expected. And its application in these “Multimedia-Boxes”, or “Home Theater” or whatever these trendy boxes are called could mean that there is a common framework for both consumer electronic devices and a desktop environment for PCs, if KDE adopted it.
I’d love to see Jack become the standard for audio daemons.
It works, it’s professional, it allows access to hardware monitoring, and it’s very easy to develop apps for.
It also supports a sample accurate transport so all your apps can sync to each other and stop/start/rewind together.
At the moment I use it for apps like mplayer and alsaplayer as well as music apps, and it works fine, and *RIGHT NOW*, not at some unspecified time in the future when everything is finished.
The reasons I don’t think it will become the standard are that it does not support video or midi, it uses a callback based arch where all the apps run in the context of Jack, and it relies on CAPS or running as root for reliable low latency operation. (Though I imagine there may be no way around the last point for any audio server).