Phonon and the Future of KDE Multimedia is running a very informative article on Phonon, the new multimedia layer for KDE 4. It explains the rise and fall of Phonon's predecessor aRts and elaborates on the ups and downs of an audio abstraction layer. The article also gives an overview of common use cases and provides some example code. The Phonon website itself provides more code examples and documentation for using the Phonon API and for writing a backend. In addition to the existing NMM backend by Bernhard Fuchshumer, Tim Beaulen is working on a Xine backend for Phonon.

Dot Categories: 


by Mårten (not verified)

Have you tried it?

I've been using it on Ubuntu since Breezy, it works great.
For what gstreamer doesn't eat I use VLC.

by xin (not verified)

> The problem is, xine is just a playback framework.
> It doesn't help people who want to do other multimedia things,
> like actually make a video.

And isn't phonon supposed to abstract playback, and not advanced things like making a video?

by Dynamic Backends (not verified)

Will Phonon be able to switch engines dynamically dependant on MIME type, KIO Slave and availability?

What I mean is for instance:

- user wants to play local vorbis file
- Phonon delegates to xine engine
- now user wants to play remote real audio stream
- Phonon delegates to helix engine, if it's available
- user wants to play podcast
- gstreamer engine handles podcast metadata best (let's assume), so let it do the job

If the best engine for the job isn't available, talk to the second.

This would really be a huge improvement, and (I assume) easy to implement. I've seen non-technical users stumbling over media too often just because the right amarok/kaffeine engine wasn't active.

As a matter of fact it would be just like magic! ;-) (which is much better than today's 'just like hell')

Of course this might not apply to windows, for instance, where it might not be needed or not be doable, but on Linux/UNIX I could finally tell people that they can play mostly everything if they switch to it.

Configuration could then be done in a cascading fashion:

- KDE ships its set of rules, assumed to be best for most people
- distributors know better how a specific engine works for them, so they tweak the rules (or they don't, if there's no need to)
- in the assumingly very rare circumstances when this is actually needed, the user can decide to learn about it and change some rules. However this is almost never needed.

by Dynamic Backends (not verified)

Actually I've just realised that this is actually a feature request, so I've posted it on BKO.

Those interested in commenting or in voting can reach it at

by Corbin (not verified)

This shouldn't be needed, pretty much all of the engines you listed (xine, helix, gstreamer) should be able to do all of those things easily. The only reason you would want to do something like that is if the backend is broken (which the devs said broken backends won't be shipped).

by ac (not verified)

> pretty much all of the engines you listed (xine, helix, gstreamer) should be > able to do all of those things easily

They should be able, but they never are. The amaroK xine backend doesn't handle audio cds (I mean amaroK 1.3). Besides, xine can play at most 70% of all real audio streams, which means not enough. And xine is incidentally the most capable amaroK backend of all.

Which means learn from experience and use the best tool available for the job.

by AC (not verified)

I don't think phonon will not work that way, but more like this:

- user wants to play local vorbis file
- KDE delegates to kaffeine, wich uses phonon to acces xine engine
- now user wants to play remote real audio stream
- KDE delegates to realplayer wich uses helix engine,
- user wants to play podcast
- KDE delegates to amaroK, wich uses phonon to acces xine engine

by Dynamic Backends (not verified)

What you have in mind is the mapping of MIME types to applications, which is already happening nowadays. This issue belongs to the file manager, not to the multimedia infrastructure.

What I mean to say is that backends (not applications) are not equally good with handling different mime types, and that they are not equally good with handling different sources (eg. web, audio cd, hard drive etc.). Sending all audio cds to Kaffeine, for instance, will not help, as long as kaffeine happens to call xine, and the xine engine doesn't properly tell xine how to play an audio cd (I think this has been fixed in amarok, but you get the point.)

As for not shipping broken backends, this will not help at all, because ALL BACKENDS ARE BROKEN. This means there is always something important that a backend is not good at, like playing audio cds or real audio streams.

And since Phonon makes all backends available to all apllications, we should be finally free of choosing apps based on playback capabilities (since they're all equally powerful) and able to choose them based on user interaction. For instance kaffeine for video (not music), amarok for music (obviously not video) etc. This means:

media type -> app backend

real audio amarok helix
real video kaffeine helix
mp3 amarok xine
avi kaffeine xine

(of course, these are just examples)