After a short break, we return to the next interview in the People Behind KDE series, travelling back to Germany to talk to a developer who wants to make things as simple as possible - for both users and developers. The recent winner of an aKademy Award for Best Non-Application for his work on Phonon - tonight's star of People Behind KDE is Matthias Kretz.

Just for reference, http://opensuse-community.org/Package_Sources is a pretty definitive guide for setting up your repositories. On the command line this consists of pasting ~5 commands, and then you'll have all the recommended repositories (some of which are not included by default for legal reasons).

I'm interested in what low-level audio I/O actually means. As far as I have understood, Phonon wanted to abstract the low-level stuff and those who needed specialized stuff should program directly for their chosen backend. Does it mean additional "pro-audio" support with the ease of the Phonon libs for those who need it?
A bit unfortunate (regarding look and feel e.g.) is that almost all pro-audio programs (that use Qt) use Qt only but not KDE. Or is that because most are done with Qt4 while KDE4 is not out and stable yet (so too much hassle to already add support for)?
Not counting Krecord, which doesn't count as pro-audio anyway ;-)

For the applications using Qt4, the lack of KDE 4 may be a reason for not being a KDE app. For others it may be as simple as the authors don't feel they need the extra stuff they get by being a KDE app. And it seem the audio programs in general love to do their own solutions, like the way they do with all those self made widgets.

Yes, I saw that Rosegarden was surprisingly the only app which makes use of KDE. Which is Qt3/KDE3 actually, which again probably points into the direction of KDE4 not yet being ready.
The custom widgets and knobs thing is true, perhaps coupled with the feeling that Qt4 gives almost everything needed. At least I've read much enthusiasm on several projects about how Qt 4 already boosts the development.
It'll be interesting to see how much pull and appeal KDE4 can create to offer an incentive to do a porting -- which they can't refuse ;-) (though I'm still interested what the further Phonon plans are/mean)

Thanks to you I learned quite a bit. School was boring so I printed out the whole KView sourcecode and read it in class. Obviously with the KDE2 libs KView should have looked a bit different, but perhaps because of that I learned a few things about C++ that I wouldn't have learned otherwise.

The window titled "Tutorial 4" in Matthias' desktop screenshot has a redundant border. Why not make these borders 0 by default so that application developers (like Matthias) don't need to remember to remove them one by one and so that desktop real estate isn't wasted?

If you don't like Christianity just say that. There's no need to go through the evasion of turning simple answers to simple questions into a fault of Matthias.

Personally, as a kid, I was very influenced by Santa Claus. You believing or not believing in Santa Claus doesn't change the fact that the influence, because of my belief, was real.

People of KDE is about finding out about the real people behind KDE; I may find Taj not trimming his beard, Coolo liking bad euro-pop or Matthias making ascii art fish in his email signature strange, but in literary terms it's what gives depth to their characters and that seems to be the point of this interview series.

PulseAudio is a sound server. It's designed to be flexible, supporting network transparency, providing a drop-in replacement to dmix (ALSA plugin), ESD and JACK (protocol emulation), and allowing you to manually connect producers to sinks or set volumes for individual producers if needed (like aRts did). However, as far as I can tell, it does NOT do any decoding: unlike aRts, one can't send a Vorbis, FLAC, MP3 etc. file directly to PulseAudio, it wants an audio stream. Video is also outside of its scope.

Phonon provides a backend-independent API for multimedia, the application programmer can give it an audio or video file and it will play it. As I explained above, PulseAudio doesn't do decoding or video, so Phonon won't use it directly as a backend. Instead, using Phonon with PulseAudio will work like this:
* Your application uses Phonon.
* Phonon uses Xine to do the decoding.
* Xine then outputs the video over something like Xv and the audio over something like PulseAudio.
(There are other Phonon backends in the work, for example a GStreamer backend, but that will work essentially the same way with GStreamer instead of Xine.)
The "something like" means there's configurability here, distributions will pick a sensible default, and users will be able to set them.

The gain over KDE 3 here is flexibility through separation of concerns: in KDE 3, the application sent a multimedia file to aRts and aRts did everything else. Sounds simple, but this means all of aRts is needed: its codec infrastructure, its sound server etc. If you want to use a different sound server or none at all (e.g. because your sound card supports ALSA hardware mixing or because you value absence of latency over concurrent soundcard access), you're out of luck. In KDE 4, the application sends the multimedia file to Phonon instead, decoding is taken care of by xine-lib (code reuse!), and the output can then be sent to one of the many output plugins xine-lib supports. And xine-lib won't be a hard requirement either, a GStreamer backend and native backends for Win32 and OS X are in varying states of planning/development.

> I'm all but sure that Pulse is not intedended as a drop in replacement for JACK or aRts.

I never claimed it was a drop-in replacement for aRts, in fact I explicitly highlighted the differences! If you want to use PulseAudio while still having aRts-using apps, you'll have to run both. One possible setup is to have aRts set to output to ESD using PulseAudio's ESD emulation. (WARNING: When I tried this, I had to turn off full duplex in aRts. If you don't, you'll get an extremely unresponsive system and aRts doesn't work.)

For JACK, it looks like I was indeed wrong when I said it's a drop-in replacement:http://pulseaudio.org/wiki/Modules#JACKConnectivity
So you will need to have JACK running if your apps use JACK, however PulseAudio can work together with it (i.e. JACK output will be forwarded to PulseAudio).

Well, it might be usefull for Qt apps which want to make limited use of KDE, like only the file-open dialog. But if you really want all the added benefits of the KDE libs, like the KIO slaves, KParts, toolbar stuff, shortcut editor, Kwrite text input field, Solid, Phonon, Decibel, Sonnet and all other infrastructure - there is no 'optional' or you'll just have to do everything twice.