Phonon [LWN.net]

Phonon

Posted Jul 30, 2008 9:44 UTC (Wed) by togga (subscriber, #53103)
In reply to: Phonon by nix
Parent article: KDE 4.1 released

I've now briefly looked at the Phonon API and it appears to me that it's only a subset of
GStreamer API [high-level components] with some added widgets. Both use the same basic concept
of linking objects together - Phonon calls it "Path" and GStreamer calls it "Pipe".


>> KDEish API 

I think you nailed it here. The API is rather redundant to GStreamer - both in concept,
simplicity and portability. It should've been easy to adapt GStreamer instead of using Phonon.

It's all about the K's and the Q's. I think this is a pity since the Phonon abstraction layer
will rather scatter resources than focus on producing one top-class framework.


>> Large and overwhelming to the new user

Sure, GStreamer has a more complex model, but it's rather easy to understand - and probably
worth it once you want to do a lower-level operation.

What will be interesting is - if Phonon API turnes up not enough for some applications - will
the Applications
1. move to GStreamer
2. start requesting and implementing features in the Phonon API
3. dig up backend components and perform low-level operations

My guess is that the shortest path (3) will be chosen until the application is so messy that
it either dies a natural death or take a big leap to (1) - unless community-gods are with you
and provide you with (2) which is the case where Phonon converges to a K version of Gstreamer.


>> cross-platform portable

I think that implementing a backend for Phonon to another platform should be no less
complicated than implementing a handful of low-level components for GStreamer.

(Log in to post comments)

Phonon

Posted Jul 30, 2008 15:26 UTC (Wed) by dkite (guest, #4577) [Link]

It's quite simple.

An application written today for KDE 4.0, which has a button that produces a
'bleep' sound, will work without recompile or code changes in KDE 4.6.11.

That is the goal. Usual caveats apply, no Gcc abi changes, all else being
equal, etc.

Gnome has a different goal and structure, of incremental changes that all
applications adapt to over the life of a series. GStreamer changes api/abi,
the whole project follows.

KDE has a goal of binary compatibility. I don't think GStreamer has or is
willing to guarantee such api/abi stability for the next, what, 5 years. So,
it's either roll your own, or abstract the lower level drivers. GStreamer can
change as it will, phonon will be maintained to work with the changing
drivers, and the application button will make the 'bleep' sound.

Derek

Phonon

Posted Jul 31, 2008 0:00 UTC (Thu) by togga (subscriber, #53103) [Link]

Finally, with enough eyeballs, all confusion are shallow.

Thank you for this explanation! There was a lot of confusing arguments floating around.

Phonon

Posted Jul 30, 2008 17:20 UTC (Wed) by Sutoka (guest, #43890) [Link]

>It's all about the K's and the Q's. I think this is a pity 
>since the Phonon abstraction layer will rather scatter 
>resources than focus on producing one top-class framework.

Actually before Phonon existed there were GStreamer bindings in KDE's SVN (intended to be used
for KDE4). Except then the GStreamer API was changed and the bindings broke. By the time KDE
4.0 was released, the API was changed yet-again.

>Sure, GStreamer has a more complex model, but it's rather 
>easy to understand - and probably worth it once you want 
>to do a lower-level operation.

The nice thing about Phonon is the fact that not everyone wants or needs to do low level
operations. 

>What will be interesting is - if Phonon API turnes up not 
>enough for some applications - will the Applications

Phonon isn't *supposed* to be enough for all applications. An advanced audio editing
application is *not* the intended audiance for Phonon. Phonon is meant for the higher level
applications like exist in KDE's Edutainment module and Amarok/Kaffeine (which had already
been maintaining their own API abstraction layers internally).

Phonon

Posted Jul 30, 2008 19:35 UTC (Wed) by k8to (subscriber, #15413) [Link]

> I think you nailed it here. The API is rather redundant to GStreamer - both in concept,
> simplicity and portability. It should've been easy to adapt GStreamer instead of using
Phonon.

You are missing the forest sir.  Phonon *is* adapting GStreamer.

Phonon's reduced exposure of functionality is a feature.  By limiting the functionality
provided to the set that "desktop appplications" are likely to use, the effort required to
maintain an ABI-compatable layer on all shipping KDE platforms is remarkably reduced.

It may be that GStreamer would do all that work for KDE, and thus using GStreamer would be
less work, but those ARE NOT GSTREAMER'S GOALS, and when the paths diverge, KDE would not have
their goals met. 

It's that simple.

Phonon

Posted Jul 30, 2008 23:56 UTC (Wed) by togga (subscriber, #53103) [Link]

Sure it does. If they didn't have to do Phonon, then they should do something else at that
time. Maybe contribute to GStreamer, maybe not coding at all or maybe contribute to the
community in other ways.

It works the same way, except the decision is in the head of the individuals. But with enough
individuals and statistics...

Phonon

Posted Jul 31, 2008 1:55 UTC (Thu) by dkite (guest, #4577) [Link]

Ok, let's imagine some reality.

In kde-edu, there are 24 (ish) applications, many of them make noise of some
sort. Not music players, editors or anything that need very high level of
control over the hardware. They make noise, music in games, voice, etc. Some
record.

If they wrote to Gstreamer, right now, they would all do the calls that a
comment above quoted.

Say, at one point in the next 5 years, GStreamer changes it's api. What would
happen is of the 24 apps that use sound, they all would need to write
something like:

if (gstreamer version x)
  this api call
if (gstreamer version y)
  that api call

KDE likes in situations like that to create a library so that the same code
complexity doesn't have to be repeated in every application.

So you see, phonon is a solution to a problem that will exist. And since the
abstraction layer (kde is full of them) already exists, other problems can be
addressed, such as platform abstraction, and abi stability.

The idea that someone writing KLatin is somehow stealing development
resources from GStreamer if they want an abstract noise making api that is
api/abi stable for the life of the series is absurd.

Derek

Phonon

Posted Jul 31, 2008 10:51 UTC (Thu) by togga (subscriber, #53103) [Link]

Sorry to have confused you, this little sub-thread was a side-step and not about Phonon
itself, it only used Phonon as an example in a misleading way.

Yes. It good to see that this thread has converged to a valid explanation.

I also hope that GStreamer will be _used_ default by the distros out there. With the pluggable
backends, he KDE team went one step further than just make a new API. So the decision is still
not to embrace GStreamer and leave it out in the cold.

For example: Instead of using GStreamer for Windows [which should be really easy to do wrt how
well Phonon/GStreamer models match], they have implemented a new back-end for Windows using
the proprietary dShow API.

These are the active choices KDE has made that brings the original concern [scattered
multimedia focus] up to the table again. Now, not only the GStreamer API is in question but
also its functionality. And a short path of not implementing that fuctionality in GStreamer
[for example a MPlayer plugin].

To summarize: KDE had valid reasons for making a new Phonon API, but they have not embraced
GStreamer.