This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Phonon and the future of KDE multimedia

By N. Sanders on May 09, 2006 (8:00:00 AM)

Share    Print    Comments   

The development of the next generation of KDE kicked off with the release of the Qt 4 toolkit and aKademy conference last August and is now in full swing. KDE sub-projects from Kate to KWin are deep in the midst of planning and coding for the next major overhaul to GNU/Linux's most popular desktop. Each of KDE's applications must be rewritten to take advantage of Qt 4 and improve the look, power, and usability of KDE. The latest development announcement is for Phonon, KDE 4's multimedia framework, and the replacement for KDE 2 and 3's aRts.

aRts has drawn the ire of developers and users for years, having long ago become unmaintained and outdated to the point where prominent KDE projects such as audio player amaroK no longer bother with it. aRts cannot compete with more modern multimedia frameworks such as Gstreamer and Helix, which do more of the developers' work for them by transparently handling dozens of audio codecs for playback, mixing, and editing, and even do video. Other desktop environments such as GNOME and Enlightenment have already standardized on such frameworks.

Clearly, aRts could not serve as the next generation KDE multimedia framework, but, given that KDE's emphasis on integration effectively discourages adoption of established projects, what would? The solution will come in the form of a front end to these established frameworks, one for which plugins can be written to support any contemporary or future multimedia back end that has the basic features the Phonon API must provide. Phonon will support a sensible median of the playback, mixing, and effects features of Gstreamer, Helix, Xine, JACK, NMM, and other back ends (even aRts), while presenting them to developers in a simple and unified API. The choice of which back end to use, if the user has several installed, will be user-configurable, with some power reserved for applications to choose or recommend their preferred back ends.

Phonon's API will work no differently than any other Application Programming Interface. That is to say, it will be a layer of abstraction between KDE applications and the world of media handling. KDE apps will make calls to the list of functions that Phonon offers, and Phonon will, in turn, reroute those calls toward the chosen back end. Phonon's plugins essentially translate the calls made to Phonon's API to the APIs of other multimedia frameworks. By this method, developers can play videos, record from microphones, lower the volume, or do anything else they require with just a few lines of code that will work no matter whether the user prefers Gstreamer or Xine.

Though they are two rather different things, a comparison between aRts and Phonon should leave little doubt in a programmer's mind as to which he would prefer to use. aRts is a sound server with a low-level media framework API, whereas Phonon is a high-level, task-oriented API that leaves the low-level dirty work to its back ends. Phonon lead developer Matthias Kretz gives the following code comparison:

"In aRts, to create a PlayObject for a URL [and] connect it to the output, a few checks and asynchronous handling was necessary. With Phonon this is all done in the background."

Sample code in aRts
void ArtsPlayer::play(const FileHandle &file)

   if(m_server->server().isNull()) {
       KMessageBox::error(0, i18n("Cannot find the aRts soundserver."));

   if(!m_playobject || !file.isNull()) {

       delete m_playobject;
       m_playobject = m_factory->createPlayObject(m_currentURL, false);

           connect(m_playobject, SIGNAL(playObjectCreated()),


void ArtsPlayer::playObjectCreated()

It's much simpler with the Phonon API: 
void ArtsPlayer::play(const FileHandle &file) { if(file.isNull()) return; m_currentURL.setPath(file.absFilePath()); m_mediaobject->setUrl(m_currentURL); m_mediaobject->play(); }

Kretz also says that Phonon will implement "per-application software volume controls, grouped into categories," which means that video players can be cranked all the way up while notifications are relegated to quiet beeps in the background. This ought to be a welcome usability enhancement to those who wonder why every application must have its own volume control, and some none at all. He continues, "Phonon will let applications do multimedia in-process (well, if the back end does it like this). With aRts, everything was running in one thread in the artsd process." A common problem in today's KDE is one faulty program taking down the entire sound server; Phonon should help to limit that.

Kretz is excited about the advanced hardware handling that Phonon's cooperation with KDE 4's Solid hardware compatibility project will provide. He gives the following example of what can be done by this tandem:

  • You're working on your computer, and a VoIP call comes in.
  • You answer the call while searching for your USB headset.
  • While talking to the other side via the internal mic and speakers you plug in the USB headset.
  • Solid notifies Phonon about the new sound card device.
  • Phonon sees that the Communication category prefers the USB headset over the internal soundcard.
  • VoIP program switches to the USB headset and a passive popup notification shows the change and a button to undo the switch.
  • Standard KDE notifications are still played through the [speakers] as the preferred output for the Notification category is the internal sound card.

Configuration of which application category uses which hardware output will likely be done via a KControl module. Because Phonon relies on independent multimedia frameworks to do the actual media handling and hardware I/O, it should also be more portable than aRts was, and KDE 4 has a focus on portability.

Not without limitations

Phonon can't do everything, though. Kretz warns that some developers may need to access back ends directly. "To design the Phonon API I did not look at what the frameworks can offer but at what the applications need to do. In the end I defined a functionality that a Phonon back end has to supply.... That means that the full power of the media framework that is used to implement a back end is not available to the developer using only the Phonon API. I guess it's probably the 80 - 20 rule: 80% of the developers will be satisfied with what Phonon can do, 20% will need more power/control/features and will need to use something else together with Phonon or completely without using the Phonon API at all."

Although it was announced on April 27, much of the work for Phonon is already finished. Phonon's roadmap indicates that the project design and even the playback API have been drafted. Early reaction to the API has been positive, with commendations for its simplicity. A reference back end has also been implemented, and the first working one is under construction for Network-Integrated Multimedia Middleware. Ahead of the Phonon team lies some testing and work on the audio-video effects and capture APIs, all of which is in the preliminary stages. The team expects Phonon to be integrated with the KDE 4 codebase around June, with work on a network API to follow.

Phonon is just one of the initiatives that are bringing developers together to make KDE 4 a better designed desktop than its predecessors. Appeal is a collaboration of designers who are seeking to improve the appearance and visibility of KDE through projects such as the new SVG icon theme and visual motif Oxygen, hardware accelerated animations labeled Coolness, and desktop search engine Tenor. The Plasma coalition is rethinking the desktop interface, which they believe is "essentially the same as [it was] in 1984." The aforementioned Solid is improving hardware support to help applications manage things like USB devices and wireless networks dynamically as they are connected and disconnected. This system of initiatives is unique in that they are not isolated software projects, but rather groups of people dedicated to enhancing specific qualities of KDE across its many constituents, writing new code where needed. Each initiative has also been accompanied by a fair amount of enthusiasm and discussion thanks to strong marketing, building excitement and hype for the eventual release of KDE 4 in early 2007.

Share    Print    Comments   


on Phonon and the future of KDE multimedia

Note: Comments are owned by the poster. We are not responsible for their content.

Nice article! Something to add:

Posted by: Anonymous Coward on May 09, 2006 10:56 PM
A very nice article. Well written, and full of information. Well done<nobr> <wbr></nobr>:-)

Here some thoughts I had while I was reading the article:
Some people complain that it is dubbling of effort to write Phonon and that it would make sense to integrate gstreamer directly since it *is* the de facto standard at the moment and could also emerge into a Linux standard.

The knowledge which is missing in these cases (and I miss in the article a bit also) is that there has to be an API for KDE even if gstreamer would be integrated as the only solution:
KDE developers are used to KDE APIs, and gstreamer has nothing similar, so even with gstreamer KDE would have Phonon.
And together with the history of aRts and the fact that gstreamer is nice, but still far away from perfect and that the competitors of gstreamer are quite strong also, it just makes sense to expand the API to adopt more than one backend.

And about 80-20 - if you write a professional application you normally try to access the underlying framework as close as possible - like gstreamer, helix or even direct ALSA, etc. And in these case you also need the framework - imagine a helix based program in a non-flexible gstreamer environment. That would be bad. In KDE 4 you could just switch Phonon to the helix backend, and everything, your normal apps plus the high professional app, is working with helix. There would be no need to start both multimedia frameworks.


Re:Nice article! Something to add:

Posted by: Anonymous Coward on May 10, 2006 01:27 AM
"Some people complain that it is dubbling of effort to write Phonon and that it would make sense to integrate gstreamer directly since it *is* the de facto standard at the moment"

The shere inaccuracy of that statemnt alone proves that 'some people' don't know what they are talking about. It's rather pussling to se Gstreamer reffered to as de facto standard in this context(Desktops), standard where I'd say.

Not in Gnome and not anywhere else for sure. It's NOT a standard for desktop multimedia (aRts on the other hand actually are, since the whole KDE desktop system uses it), since the Gnome desktop services still relies on the ancient ESD.

One may argue and call it the standard for Gnome multimedia players, but that only confirms the lack of understanding since multimedia players only are a subset of what desktop multimedia actually are.


Re:Nice article! Something to add:

Posted by: Anonymous Coward on May 10, 2006 08:42 AM
A bigger reason we need a separate API is so that when GStreamer or Xine or NMM change their binary compatibility, then KDE binary compatibility is not broken, you just tweak the plugin.



Solid state physics

Posted by: Anonymous Coward on May 09, 2006 11:42 PM
Goo... I hate it when useful technical jargon is used to name something completely unrelated. Poor solid state physics students, googling for information on <a href="" title="">phonons</a>, will only find references to KDE soon.


Re:Solid state physics

Posted by: Anonymous Coward on May 10, 2006 04:05 AM
Try the query "phonon -kde"<nobr> <wbr></nobr>;)


Re:Solid state physics

Posted by: Anonymous Coward on May 10, 2006 10:44 PM
Solid state physics students should know better than to rely on Google<nobr> <wbr></nobr>:-)


Re:Solid state physics

Posted by: Anonymous Coward on May 11, 2006 05:41 PM
Kinda like a carpenter googling for "windows"<nobr> <wbr></nobr>;-)


Re:Solid state physics

Posted by: Anonymous Coward on May 19, 2006 05:46 AM
Or someone who wants to figure out how to move an on-screen window googling for windows<nobr> <wbr></nobr>;)

Not that this proves the poster wrong however; MS shouldn't have been allowed to use that word as a trademark.



Posted by: Administrator on July 06, 2006 06:19 AM
awesome article, though it sounded alot more technical then it is.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya