[dot] The Road to KDE 4: Phonon Makes Multimedia Easier

[Dot Stories]

URL: http://dot.kde.org/1170773239/

From: Troy Unrau <troy.unrau at gmail.com>
Dept: can-you-hear-be-now
Date: Tuesday 06/Feb/2007, @06:47

The Road to KDE 4: Phonon Makes Multimedia Easier
=================================================

   Like the previously featured articles on new KDE 4 technologies for 
Job Processes [http://dot.kde.org/1169588301/] or SVG Widgets
[http://dot.kde.org/1167723426/], today we  feature the shiny new
multimedia technology Phonon [http://phonon.kde.org/]. Phonon is
designed to take  some of the complications out of writing multimedia
applications in  KDE 4, and ensure that these applications will work on
a multitude  of platforms and sound architectures. Unfortunately,
writing about  a sound technology produces very few snazzy screenshots,
so instead  this week has a few more technical details. Read on for the
details.

     Phonon is a new KDE technology that offers a consistent API to use
audio or video within multimedia applications. The API is designed to be
Qt-like, and as such, it offers KDE developers a familiar style of
functionality (If you are interested in the Phonon API, have a look at
the online docs
[http://www.englishbreakfastnetwork.org/apidocs/apidox-kde-4.0/kdelibs-apidocs/phonon/html/index.html],
which may or may not be up to date at any given moment).

     Firstly, it is important to state what Phonon is not: it is not a
new sound server, and will not compete with xine [http://xinehq.de/],
GStreamer [http://gstreamer.freedesktop.org/], ESD, aRts
[http://www.arts-project.org/], etc. Rather, due to the ever-shifting
nature of multimedia programming, it offers a consistent API that wraps
around these other multimedia technologies. Then, for example, if
GStreamer decided to alter its API, only Phonon needs to be adjusted,
instead of each KDE application individually.

     Phonon is powered by what the developers call "engines" and there
is one engine for each supported backend. Currently there are four
engines in development: xine, NMM [http://www.networkmultimedia.org/],
GStreamer and avKode [http://websvn.kde.org/branches/work/avkode/] (the
successor to aKode) [http://carewolf.com/akode/index.html]. You may rest
comfortably in the knowledge that aRts is now pretty much dead as a
future sound server, and no aRts engine is likely to be developed.
However, aRts itself may live on in another form outside of KDE. The
goal for KDE 4.0 is to have one 'certified to work' engine, and a few
additional optional engines.

     Other engines that have been suggested include MPlayer, DirectShow
(for the Windows platform), and QuickTime (for the Mac OS X platform).
Development on these additional engines has not yet started, as the
Phonon core developers are more concerned with making sure that the API
is feature-complete before worrying about additional engines. If the
Phonon developers attempt to maintain too many engines at once while the
API is still in flux, the situation could become quite messy (If you
would like to contribute by writing an engine, jump into the #phonon
channel at irc.freenode.org).

     When an engine is selected by the user or application, Phonon will
use the selected engine to determine what file formats and codecs each
backend supports, and will then dynamically allow the KDE application to
play your media. As it currently exists in the KDE 3 series, the user
would have to manually change engines in each application (Kaffeine,
Amarok, JuK, etc.) rather than being able to select engines for use
across KDE.

     Once an engine is selected for Phonon, it allows the programs to do
the standard multimedia operations for that engine. This includes the
usual actions performed in a media player, like Play, Stop, Pause, Seek,
etc. Support also exists in Phonon for higher-level functions, like
defining how tracks fade into one another, so that applications can
share this functionality instead of re-implementing it each time. Of
course, some applications will want more control over their
cross-fading, and so are still free to design their own implementation.

     The engine with the greatest progress so far is xine, which I was
able to set up and run on my system. I was unable to get the NMM
(notoriously hard to compile/setup) or GStreamer engines to compile on
my system, whilst avKode is currently disabled by default. I would show
you a screenshot of Juk or Noatun playing audio with Phonon, but right
now these applications look just like their KDE 3.x versions (only with
a somewhat ugly/broken interface!). When they are getting polished for
release, I will show them off in a later article.

     Matthias Kretz offers a short video
[http://static.kdenews.org/danimo/phonon_device_switching.ogm] which, if
you turn your speakers on while watching, demonstrates device switching.
Phonon lets you switch audio devices on the fly, and you can hear the
specific moment when the music switches from his various outputs
(headphones, speakers, etc.).

     Matthias also submits the following screenshot of output device
selection using Phonon's configuration module. This is also a
work-in-progress, and so take it with a grain of usability salt.



     There are not many things that I can take a screenshot of which
show Phonon in use (screenshots of an audio framework are notoriously
difficult to compose!), but I can describe one of the neat side effects
of using Phonon: network transparency. KDE has long used KIOSlaves to
access files over the network as easily as if they were stored on your
local computer. Multimedia apps like JuK or Amarok should be able to add
files transparently over the network to their collections without having
to be concerned about whether or not the back-end engine is aware of how
to deal with ioslaves. This support is already partially implemented in
KDE 4, and is most visible through audio thumbnails, which are working
for many people over any KIO protocol, including sftp:// and fish:// -
two popular protocols among KDE power users. They do not yet work for me
due to some instability in the fish:// KIOSlave of my current
compilation, but the developers in the #phonon IRC channel claim that it
this functionality will be ready and working when fish:// is more
stable.

     So, Phonon, while still in development, is going to be a great
pillar technology for KDE application programmers, making their job
easier and removing the redundancy and instability caused by
constantly-shifting back-end technologies, and (eventually) making
support for other platforms a piece of cake. This means that those
developers can spend more time working on other parts of their
applications to ensure KDE Multimedia applications shine even more
brightly than they currently do.

     A couple of quickies here to note: Mark Kretschmann, lead developer
for Amarok [http://amarok.kde.org/] has officially opened up Amarok 2.0
development [http://lists.kde.org/?l=kde-commits&m=117041944607084&w=2]
this week, and seems to be quite interested in what Phonon can do for
Amarok 2.0. He doesn't rule out keeping their own engine
implementations, like they currently do in the Amarok 1.4 series.
However, given its early stage of development, Phonon can likely be
adjusted to ensure that it will do everything Amarok asks of it.

     If you're looking for a way to help out with KDE and are not a
programmer, Matthias Kretz, lead developer of Phonon (Vir on IRC) has
requested some help in keeping the Phonon website up-to-date.

     And lastly, a few translations of these articles have been popping
up around the world in various languages. Sometimes more than one
translation is happening for a specific language. If you are translating
or plan to translate these articles, send me a message so that we can
save everyone some work and avoid redundancy (lets keep the
redundancy-reduction spirit of Phonon alive!).

     Until next week...