Something new in KDE 4: Phonon

There some things which are in the focus of the news, and some which are not – one of these things which hasn’t been in the focus for a quite long time is KDEMM. KDEMM ought to be the new multimedia api, and should, together with a backend, replace aRts.

Some days ago it was announced thta KDE now gets a new, better name: Phonon.
That’s nice because it shows that the developer really think about how they want to sell their program. And it shows that we are getting rid of the “K” in the most application names 🙂

So what is Phonon now? As I wrote, it should replace the actual system in a way – that’s quite nice because although aRts was bleeding edge when it was released there hasn’t been any real development in the last years, and the project is now officially dead. In the meanwhile the rest of the world didn’t stop development, and the requirements for multimedia on the desktop developed and enhanced, too.

To give you an idea:

  • In former times there was a strong need for a soundserver to mix different audio streams from different sources – now, with Alsa since kernel 2.6, this need is not as strong as in former times because the most computers which are running KDE are running a Linux with 2.6 kernel (only the BSDs and older Linux have no Alsa).
  • In former times we had only some audio sources and normally one sound card. Today we have probably more hardware soundcards, several audio streams and these streams in and out (music + calling in from kopete/jingle, for example).
  • Today we have video also – if we really want to make a multimedia api we have to deal with Video too – and then we have to deal and manage these different streams, too, probably guiding them through different tunnels to other devices.

And there were other problems with aRts, too. Who ever tried to wrap skype over a normal built-in soundcard knows what I am talking about.

So why don’t just switch to gstreamer, you may ask? Well, the main reason is: it is hard for kde-developers which are used to Qt object model, to develop something with a glib api. If you want to attract developers, give them easy-to-use apis. Sure, you could write a gstreamer-only api to give the developers a qt-gstreamer api, but then you could rise other questions: Is gstreamer really the highest which can ever be reached? What is if there is something new, and gstremaer is not able to follow? Or what is if gstreamer does not want to work for some machines well enough, and no one wants to fix that soon because there is something more important for them? And aren’t their other projects which are very promising? Have a look at NMM for example. Why should KDE fix to one specific backend, banish all other interesting projects and get back into subjection where it wants to escape, when you in any case have to develop an api? KDE should use, and KDE does use this opportunity! Thanks a lot to vir.

If you still don’t believe me, check this discussion.

And for me? Well, I’m no developer, but I can try to convince the people what the “right way” is – and I can try to keep asking if everything really gets fully integrated. Just think of a full integrated, totally jabber-video and jabber-audio capable Kopete working together with kontact which has all your phone numbers (synchronized from your mobile phone, of course). The music comes from amarok, the video from something-yet-to-develop (or an advanced and integrated kaffeine), and everything – and that is important – just works, with the backend you want. Yes, I’m a dreamer, but that’s necessary sometimes 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s