Multimedia has now become an essential part of every computer, including those within the enterprise. While aRts was, for along time, hailed as the answer for multimedia within KDE, it fell out of favor as it became obvious that it was hopelessly inefficient. Associate Editor Eduardo Sánchez sits down with Scott Wheeler of the KDE Project to find out where the KDE multimedia department is headed in general, and concerning a replacement for aRts, more specifically.
One of the highlights of the aKademy conference held last August in Ludwigsburg (Stuttgart, Germany), was the new developments in multimedia for The K Desktop Environment (KDE). It was apparent that KDE multimedia developers were considering an exciting array of new technologies and engines, and introduced KDE users to a whole new alphabet soup: GStreamer, NMM, MAS, etc. The most surprising trend, from my point of view, was that there was strong talk of leaving aRts, and the concurrent push to look for a suitable multimedia replacement.
This was somewhat surprising, because I always thought that aRts was an excellent technology that was ahead of its time when it was released, and provided a reasonably good multimedia engine for KDE. On the other hand, I always had problems with dropped frames in aRts even with an extremely fast machine, so clearly the engine needed some polishing and tuning.
Wanting to know more about the situation, I contacted Scott Wheeler, which is the creator, lead developer, and current maintainer of JuK, an audio jukebox that supports collections of MP3, Ogg Vorbis and FLAC files, and that is getting a lot of attention for his usefulness and good design. Scott kindly accepted my request. It was very good to talk to Scott again; we are friends, with our friendship stemming back from my time in Grand Rapids, MI. I owe Scott the privilege of meeting Bradley Kuhn (the Free Software Foundation executive director) and he was the only GNU/Linux and KDE user I knew in the area.
Before going to the interview, the standard disclaimer should be made: Scott does not speak for KDE multimedia, or KDE in general. The following are Scott's views only, in his role as an active KDE developer. He said that he would try to be representative of general views, but nothing was guaranteed.
Thus, we met at the hours of the Paraguayan siesta on October 19 over the Internet for this talk. As background information, Scott suggested reading this summary of the KDE Multimedia talks in the last aKademy conference.
OfB: Scott, thanks for this interview. It is a privilege to have you for a brief talk. First of all, could you please introduce yourself briefly, stating what are you doing for a living and what is your role inside the larger KDE Project?
Scott Wheeler: Well, I suppose my standard, naturally somewhat narcissistic snippet (pasted from some recent talks) is: “Scott Wheeler is a Linux specialist who has been employed in the SAP LinuxLab in Walldorf, Germany since 2002. He has been active in several areas of KDE development in the last several years, most notably multimedia. He is the author of JuK, FlashKard, KSig, TagLib and assorted hacks throughout the rest of KDE.” — and lately I've also been working a lot on some newer things for KDE 4 related to search interfaces, organizing the various people involved in multimedia, and trying to get people looking at what's ahead for KDE 4.
OfB:Scott, I must confess that I am kind of confused when it comes to the state of KDE Multimedia. KDE has a multimedia architecture: aRts which was developed mainly by Stefan Westerfeld. I remember that back in the KDE 2 days, aRts was deemed as a huge innovation, a great multimedia architecture, and it was all the rage. Even more, I remember an application that roughly resembled Finale, named Brahms. However, after reading the latest issues of KDE CVS-Digest and all the summaries from aKademy, it is evident that aRts is being increasingly seen as a liability, and not as an asset. There's talk of “replacing aRts” everywhere. Now, I can understand some of that talk the only sound system in my workstation that produces gaps is aRts but anyway, can you enlighten us about what is really going on there? Is there something that we missed?
Scott Wheeler: Well, yes — where to start. I suppose a brief history of aRts is in order. aRts was indeed introduced for KDE 2. It was written to fill a gap at that time — well, a few gaps, actually. At that time there was a desire to have a common, cross-desktop framework to provide:
The beginnings of the introduction of aRts into KDE took place at the KDE 2 meeting. It did indeed show quite a bit of promise. Stefan pitched it to the GNOME folks at GUADEC (Gnome Users and Developers' European Conference) one year as well. aRts continued to move along for a few years and kind of reached a high point in terms of stability in 2001 or so. But as you mentioned, it was mostly developed by Stefan Westerfeld —in fact it was almost exclusively developed by Stefan, which when he became somewhat disenchanted with it eventually led to problems. I suppose we can understand those in the context of a few things that happened —or rather didn't happen.
aRts was never picked up as a cross-desktop multimedia framework. The synthesis framework never really took off in terms of application adoption and the latencies were too high for professional audio usage. This meant that it always kind of lacked the critical mass to be anything more than “the KDE sound server”. Also, as was just mentioned, Stefan eventually lost interest in maintaining it.
Now, aRts is a complex system, and multimedia is a fast-moving target. Eventually we needed things like reliable video synchronization, the ability to cooperate with other multimedia frameworks, and well, just plain old fashion bug fixes. With Stefan no longer pushing the project there were only a handful of people that understood bits and pieces of the system — nobody with a general understanding of how aRts worked enough to take over maintainership.
So most of the bugs and things that never got around to being implemented with aRts have stagnated since for the last couple of years. For such a critical component of the desktop we need something that's going to grow with KDE, and that more or less brings us to today —where both developers and users are talking about what we'll be doing for KDE 4. It should also be noted that because of KDE's commitment to providing a stable platform that we won't be removing aRts prior to then.
OfB: When did Stefan decide to abandon aRts? 2001? 2002? 2003?
Scott Wheeler: That's kind of fuzzy — I mean, there wasn't a point at which he announced such, but the CVS commits really dropped off after 2002.
OfB: That's kind of sad. aRts was and still is, I think, very promising… but on the other hand, the latencies were terrible.
Scott Wheeler: Well, and more important from our perspective —we need for critical components of the desktop to be maintained —that's true for the multimedia framework just as much as it is for our widget libraries, for instance.
OfB: Then, Scott, can you tell us something about the candidates for an aRts replacement?
Scott Wheeler: At the moment there are a couple of strong contenders for full featured media frameworks: GStreamer and NMM (Network Multimedia Middleware). There's also been some talk with the people promoting MAS (Media Application Server), but it currently doesn't provide everything that we need. I'm personally partial to GStreamer, mostly because it has a strong Open Source community around it and is fairly mature; there's a growing set of applications for both of the major desktops that currently use it (JuK was the first in KDE, but it's also now the default for amaroK) —not to mention a host of GNOME applications. NMM also shows quite a bit of promise, and has a very nice API (Application Programming Interface); but is presently at an earlier stage in development and has less community backing and mindshare.
OfB: Speaking from my experience in using aRts, I would like to ask: What about the resource usage of all these engines? Are they lean or are they resource hogs?
Scott Wheeler: I can't speak from personal experience for NMM, but GStreamer tends to be fairly lightweight. Of course this all depends on what you're doing —but the frameworks themselves don't tend to add near as much overhead as aRts does relative to the tasks that are being carried out. It should also be noted that some of this comes from the fact that they're a bit different in scope from aRts. aRts attempted to solve a lot of problems in one bundle of software; it was not just an audio framework, but also a soundserver and a synthesis framework. Both GStreamer and NMM are more lean in that regard — they're frameworks for putting other things together, but aren't soundservers or synthesis frameworks themselves.
OfB: Now I'm a bit curious about noatun, the KDE Media Player. We are hearing a lot about new media players, such as amarok, kaffeine, or others, and noatun is increasingly absent from the buzz… Is noatun still being maintained? Is there a future for it? What is the future KDE official media player?
Scott Wheeler: Well, I think the official line from Charles (author of Noatun) is that he considers Noatun mostly complete, that's why there's not that much activity there. It's hard to say what lies in the future for Noatun, but I think that gets at a deeper issue in KDE — how do we feel about applications with similar functions coexisting in the same KDE package? I don't think we have a clear answer there, though it's been debated many times — and that's not a problem unique to KDE multimedia. For the immediate future I don't think that we'll have an “official” media player. I may be proven wrong there, but I think for something like that to emerge will require a more fundamental shift in KDE's current culture.
OfB: I understand, and that looks right to me. On the other hand, don't you think that there should be a somewhat “standard” media player provided as reference?
Scott Wheeler: In fact what you ask is a hard question. Really there are two questions there — I guess I'll split them up and answer them separately:
Now, turning that back to media players. Can we make a decision on the default? Well, the closest we can really come is to decide what gets associated with which media types by default. And I think the jury's still out on that one. The group of players that is emerging right now are all exciting, but they're also not terribly mature. That may change in the next year and a half — we'll just have to wait and see.
OfB: Scott, perhaps summarizing what you've said before, can you give us a roadmap for KDE multimedia? Where is KDE Multimedia heading? Where is the place of KDE Multimedia in the future of KDE?
Scott Wheeler: Well, I suppose roadmap is probably a pretty good analogy — since there are a lot of ways to get there. Right now those of us in that are more active in KDE multimedia have tried to lay out a set of requirements for multimedia frameworks; they need to support audio and video decoding, routing that to the appropriate places (sound card, sound server, etc.) and probably some basic recording features. Then we've tried to evaluate what's available to us and how we can make use of the things that are available to best support KDE as a desktop. We learned a lot from aRts, so we're trying to make sure that the options that we're considering will be viable long term; but also we don't want to be explicitly tied to a single framework at least not yet. So what some of us started on at aKademy was a framework for abstracting away the basic features —playing stuff, mostly of the media frameworks and making that pluggable. We're pretty sure that we'll have a few implementations around and we'll be able to make a decision on what should be the default at a later time.
The general consensus at aKademy between the multimedia developers is that GStreamer will probably be the most suitable default. But that also means that packagers, administrators and in some cases users will be able to choose what best fits their needs. Naturally we would hope for a default solution that “just works”, will be maintained forever, never change its interfaces in a binary incompatible way and solve world hunger, but I suppose we've grown a bit more cynical and cautious. Right now it looks like the best way forward is to pick the most sane default that we can, and hope that users won't ever have a reason to change it; but also to insulate ourselves from being locked into a single framework for the entire KDE 4 lifespan.
OfB: Thanks, Scott, for your time.
Scott Wheeler: Sure.
Eduardo SÃ¡nchez is a Contributing Editor of Open for Business. He is married to Gloria, and lives with his wife in AsunciÃ³n, Paraguay (South America), where he works as pastoral assistant of Villa Morra Baptist Church. You can reach him at firstname.lastname@example.org .
|Home About Connect: Twitter Facebook RSS|