The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
[Posted February 6, 2007 by ris]
KDE.News looks at Phonon.
"Like the previously featured articles on new KDE 4 technologies for
Job Processes or SVG Widgets, today we feature the shiny new multimedia
technology Phonon. 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."
(Log in to post comments)
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 18:46 UTC (Tue) by ajross (subscriber, #4563)
[Link]
How, exactly, is this any different from gstreamer? I mean, I read the article, and it *says* they are different. But it doesn't actually say how. It looks to me like this is yet (!) another streaming media abstraction API. Does the world really need another one of those?
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 18:53 UTC (Tue) by stumbles (guest, #8796)
[Link]
The gist I get is it's more or less a wrapper so when the APIs for gstreamer, etal change the
kde folks only need to alter Phonon API instead of multiple other KDE APIs.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 18:55 UTC (Tue) by aleXXX (subscriber, #2742)
[Link]
Yes, it's one one sind a convenience layer so application developers can
user a higher level API and on the other side it hides the actually used
sound system, so it wouldn't be a problem if gstreamer changes binary
incompatible or some other sound system becomes the first choice.
Alex
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 22:32 UTC (Tue) by TRauMa (guest, #16483)
[Link]
I'm not so sure that'll work, though. On the other hand, this quite in line with any other library/framework KDE is using apart from QT: they all get wrapped. No big surprise, if you just see it as an effort to provide devs with a homogeneous environment.
Perhaps it's just like the KDE devs say: it would help if gstreamer would be clearly superior. Right now, it's not.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 18:59 UTC (Tue) by cventers (subscriber, #31465)
[Link]
The KDE devs have been burned before by the audio system breaking,
changing ABI or becoming unmaintained... Phonon doesn't replace the audio
system; rather, it is a shim over the audio system such that if the audio
system must break or change, only one library must be rewritten /
recompiled in KDE instead of every KDE audio program.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 19:02 UTC (Tue) by johnkarp (subscriber, #39285)
[Link]
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 19:38 UTC (Tue) by ajross (subscriber, #4563)
[Link]
That's a good post, and much clearer than the linked article above.
It's a reply to this post from
Christian Schaller, which is also clear and informative. So it
seems my question above managed to step right into a pre-existing
flame war, alas.
Nonetheless, I'm not sure I quite buy into the Phonon spin on this
one. There just isn't a clear definition for "media engine". At the
bottom of the stack are device drivers and codecs. But everything
above that is just (er, "just") an abstraction layer. So GStreamer
and aRts are media engines. So is OpenAL, which has similar features
but is aimed at a different community. Ditto SDL. Even parts of ALSA
fit this description. And the worst part is that all of these guys
can play to or be played by most of the others, so you can't just chop one out of the stack to simplify things. It's a cyclic mesh of dependencies, and it sucks.
So I just don't see what's special about coming up with another
API that can play to all the other ones. I mean, sure, in the Phonon
thinking this API will always be "on top" and therefore "just" (that
word again) an abstraction library. But in reality this is
exactly the thinking that got us into this mess in the first
place. How long until someone hacks up a gstreamer module that is
backed by Phonon so they can use a Gtk+ video app on their KDE
desktop? What happens then?
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 20:36 UTC (Tue) by quintesse (subscriber, #14569)
[Link]
For me there is a very good example: Amarok. It's yet another program
that had to re-invent the entire media-engine plug-in system idea to be
able to support all the different options that exist.
Now you could say that we should all just use gstreamer and be done with
it but first of all that would make lots of people who prefer to use
another engine very unhappy and secondly IMO it goes against the very
idea of KDE where just about anything is pluggable (not even mentioning
other platforms where using gstreamer might be a silly thing to do).
And the GTk-app example might be actually come about but I don't think
KDE-developers should focus on those possibilities. We're talking about
KDE afterall, it should be as easy as possible to run KDE apps, that it
might be slightly more difficult to run GTk apps seems like a small price
to pay.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 20:49 UTC (Tue) by ajross (subscriber, #4563)
[Link]
you could say that we should all just use
gstreamer and be done with it but [...] that would make lots of
people who prefer to use another engine very unhappy
This isn't really a good forum for flame wars, so I'll resist.
But one point does bear mentioning: The logical corrollary to
this statement is that your opinion (or rather, the composite
opinions of "lots of people") is that the current messy soup of
media APIs is a good thing that is worth preserving.
I don't really have a counter argument to that. If you are
happy with all the junk out there, then by all means add better
junk. The (mild) flame was predicated on the assumption that all
this variance, incompatibility and duplicated effort is a net
loss to the community.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 22:39 UTC (Tue) by jospoortvliet (subscriber, #33164)
[Link]
well, if some day a developer decides to make a multimedia engine which
provides exactly the same interface phonon does for the apps, and which
eliminates all layers - problem solved. point is, this solves a problem.
which is good. the KDE dev's can't fix the 'real' problem, and this works
great, even if there comes a 'real' solution...
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 5:24 UTC (Wed) by dkite (guest, #4577)
[Link]
Lets deal with reality. Amarok supported gstreamer, among other engines.
They dropped it because of api breakage, and lack of time or desire to
keep it up.
There are a number of engines, each with different focus' and
capabilities. Arts is dead, what all kde3 apps link to.
What would you do? What you propose is probably a couple of years after
kde4 is ready. It isn't the situation right now.
So do we hold back kde4 until everything else is ready? noise is an
integral part of the desktop.
I agree. This is another layer on top of layers. So does kde break each
time the 'chosen' multimedia engine changes api? What does kdeedu do,
education software that doesn't have complicated noise requirements, but
they are essential to the operation. A dozen or so apps would be broken
each api change.
To quote a military term, embrace the suck. The situation sucks.
Dependencies on other projects for core parts of your desktop sucks.
Having to change (insert large number) lines of code in the large project
that is KDE each time the dependency changes sucks. The idea of a layer
sucks for many reasons. It all sucks. So, in 6 months or so before kde4 is
ready, what can be done?
Phonon.
The kernel works very well with drivers as part of the project because
they can change stuff internally as long as the api stays close to the
same. Xorg is thinking of demodularizing the drivers to enable
improvements at that level. Kde has worked well with most important
libraries within the project. Dependencies suck. I think the lib and api
model is broken and the solution should be found there.
Derek Kite (who has no ideas how to fix it)
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 5:31 UTC (Wed) by dkite (guest, #4577)
[Link]
The situation you describe would be no problem. Say you want to use kde
and a gtk video/audio app that talks to gstreamer. So you install and
configure gstreamer, set phonon (hopefully it would just work) to use
gstreamer for the kde noise requirements. No need for a phonon/gstreamer
thingy for the gtk app, because it talks directly to gstreamer.
This implementation has little to do with multimedia capabilities. It is
all about having a stable api for kde apps that need to make noise.
Remember, in kde3, we had our own multimedia engine. Arts, which is no
longer maintained.
Derek
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 8:14 UTC (Wed) by drag (subscriber, #31333)
[Link]
It also was very badly designed, which is why it's not maintained. Sure at the time it probably seemed like a good idea, but it wasn't.
(Of course with ESD that was bad from the beginning. :-P )
As for KDE using gstreamer vs phonix.. it's fine if KDE wanted to go their own. Sure it's going to be mostly useless to all applications that need to have more then a few beeps and such. While any sort of fairly complex and relevent multimedia application is probably going to end up doing what Amarok is doing and supporting a half dozen different APIs at once in order to get the support they need. But that's their crutch to bare and it's what they want.
They are probably better off avoiding gstreamer anyways. It's still not stabilised. It realy isn't. Not until people are able to do development of applications with distro-provided gstreamer versions is it going to be any good for anything other then playback.
Right now, at least it seems that way, any sort of in-development application that realy tries to leverage the power of gstreamer is in use-gstreamer-cvs-only mode.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 8:36 UTC (Wed) by drag (subscriber, #31333)
[Link]
I don't mean to sound insulting or anything, I am just tired.
So don't take this the wrong way.
What you KDE folk are saying, essensentially is:
(in steps)
* We made a bad choice with Arts.
* Our lesson from that is: "making choices are bad."
(rather then a lesson like: "Don't design something like arts again".)
* So therefore we designed Phonix so we don't have to make a choice.
So the logic behind all that seems a bit.. scewed.
Now I don't nessicarially think that Gstreamer was the right choice, per say.
Nor do I think that making it simple for simple apps is a bad idea either. (Gstreamer does seem like a bit much for many applications.)
But it makes sense to me to pick one. For instance maybe MLT? http://mlt.sourceforge.net/
Diva developer, who formally tried out gstreamer, wants to move to it. Kino wants to use it also. It's actually used in real-world now by a variety of applications, and has very minimal dependancies.
So you'd have something like phonix for simple apps, then that interfaces with MLT or something like that.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 17:36 UTC (Wed) by jospoortvliet (subscriber, #33164)
[Link]
> * We made a bad choice with Arts.
At the time it was the best audio framework available, and the KDE dev's
expected the gnomes to start using it as well.
> * Our lesson from that is: "making choices are bad."
> (rather then a lesson like: "Don't design something like arts again".)
KDE didn't design aRts, it was available like gstreamer, nmm, xine, vlc
etc are now (tough there wasn't as much quality choice as there is now).
> * So therefore we designed Phonix so we don't have to make a choice.
But even if you make the best choice (which aRts was), things can go
wrong. So better do something which can't go wrong at all - Phonon. And
you get an easier API and several powerfull meta-control features for
free.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 22:14 UTC (Wed) by nix (subscriber, #2304)
[Link]
Even phonon's *name* is telling you what their goal was: the smallest
possible minimal sound API.
It's not *meant* to handle everything, or even most things, and is really
about as unexciting as, say, DCOP in KDE3 (a thin wrapper layer over ICE).
In fact it's a lot less exciting because DCOP allowed loads of cool
things, while by design Phonon will allow simple sound playing and not
much else. Depending on an external library is rather silly when it's as
small as Phonon is: the extra pain from the extra dependency far outweighs
the trivial maintenance burden.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 7, 2007 4:40 UTC (Wed) by robert_s (subscriber, #42402)
[Link]
It's higher level. It should allow a developer to just drop a 'player' widget (for example) straight into an application.
The Road to KDE 4: Phonon Makes Multimedia Easier (KDE.News)
Posted Feb 6, 2007 19:39 UTC (Tue) by beoba (guest, #16942)
[Link]
So how soon can we be expecting another wrapper for this wrapper wrapper?