Phonon-Trolltech

It's been a month already since I was at the Trolltech office in Oslo, but ever since I wanted to write about it...

Trolltech invited me to be able to discuss the design of Phonon or, more in general, what their needs are for a multimedia API that they want to provide with or in addition to Qt. The first three days (Wed.-Fri.) we've been whiteboarding the whole day, which was quite exhausting but OTOH exactly what I always wished to be able to do when I was designing Phonon in the beginning. The outcome was that we agreed that we want to have an API that provides all the flexibility of a graph based approach while simplifying the concepts as good as possible so that non-experts have no trouble using the API for simple tasks without getting any details wrong.

Before

This is where we needed a small change in the Phonon frontend API to make this possible. Before August Phonon allowed "graphs" of the form:

Path changes

Now the AudioPath and VideoPath objects are replaced by a value based class called Path, which is hidden for simple cases: vs. or in code:

I wanted to keep the Path concept to make it easier to support the most common "graph reconnection": to insert/remove effects. With the common graph you'd have to disconnect media and output, connect media to effect, and effect to output and also somehow tell the objects that they should not lose any signal data while they're still disconnected and that playback needs to continue seemlessly after the effect insertion. With the path object it's a simple

Mixing

Another change is that is not allowed anymore. The implicit mixing of audio data is removed. (For video it was never allowed anyway). The plan is to add a special class that handles mixing after the 4.0 release. Implementation note: This is close to impossible to implement using libxine.

What's the gain?

Perhaps you've already seen it, but why is this now more flexible than what Phonon provided before? The answer is that you can now define arbitrary graphs like . In a later version we also want to have an object that can "contain" multiple MediaObjects in order to be able to control them in sync. This is basically the concept of a media graph containing multiple source nodes. But if you have only one source, which is the case for most apps, the MediaObject defines the graph implicitly. This hides the graph concept for most developers using Phonon, which IMO helps to make Phonon easier to use.

Trolltech

Now what's Trolltech's role with regard to Phonon? They want to provide multimedia API with Qt 4.4. And they decided to set their bets on Phonon. This means they will work (with me and the rest of the community that is interested) on continuing the design of the frontend API to support use cases like capture, transcoding, VoIP apps, Video chat, ... And they will work on backends for Windows, MacOS X and Linux (including embedded). KDE will ship the xine backend with 4.0, but that one has several problems:

• libxine is GPL-only, so they cannot tell commercial customers to simply use Phonon on Linux for multimedia
• libxine does not support mixing of audio streams, and I tried to separate the clock and ticket system in libxine to make it more flexible, but I feel like this is a dead end. libxine is designed for simple playback tasks and that's it.
• no capture or encoding with libxine

On another note, 2h per workday, while I'm working on Phonon, are now sponsored by Trolltech. This additional money is very welcome, especially now that we'll have to pay the rent for a flat in Heidelberg and another one in Sevilla.