Linked by Thom Holwerda on Wed 7th Feb 2007 09:09 UTC, submitted by ronaldst
KDE "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. Read on for the details."
Thread beginning with comment 210036
To read all comments associated with this story, please click here.
Over Abstraction?
by siti on Wed 7th Feb 2007 09:39 UTC
siti
Member since:
2005-07-06

I don't think it's very smart abstracting the abstraction layer. Gstreamer is an abstraction layer, so why would you want to build another one on top?

Also in the article it mentions about implementing other backends. Isn't this just duplicated effort? In my opinion they should just put more effort in to enhancing gstreamer and make good C++ bindings!

Reply Score: 5

RE: Over Abstraction?
by getaceres on Wed 7th Feb 2007 09:55 in reply to "Over Abstraction?"
getaceres Member since:
2005-07-06

1. Abstracting the abstraction lets kde people use the abstraction they want and not being attached to one. They had a bad experience with arts and they don't want to repeat the same error.

2. They need api stability and backwards compatibility across all KDE4 lifecycle (maybe some years from now on) and there isn't a backend that's going to provide that. So if a backend (say gstreamer) changes its api, the phonon team will update their libraries while maintaining compatibility with all of the KDE4 applications.

Reply Parent Score: 5

RE[2]: Over Abstraction?
by Wes Felter on Wed 7th Feb 2007 19:37 in reply to "RE: Over Abstraction?"
Wes Felter Member since:
2005-11-15

They need api stability and backwards compatibility across all KDE4 lifecycle (maybe some years from now on) and there isn't a backend that's going to provide that. So if a backend (say gstreamer) changes its api, the phonon team will update their libraries while maintaining compatibility with all of the KDE4 applications.

This could be fixed by simply maintaining GStreamer 0.10.x forever, which is probably less work than creating Phonon and all its bindings.

Reply Parent Score: 3

RE: Over Abstraction?
by kaiwai on Wed 7th Feb 2007 09:57 in reply to "Over Abstraction?"
kaiwai Member since:
2005-07-06

How so? Both GStream and Xine lack in some areas and are superior in others; for me, I find Xine in regards to better out of the box CODEC support.

The idea is to have the Xine or GStreamer or Helix Framework layer at the bottom, Phonon on top of that, and allow application developers to base their applications on Phonon without worrying what the underlying technology is, be it Xine or GStreamer or Helix Framework.

What is ensures that firstly we don't have applications glued to a particular API set that might possibly die or replaced in the future, it also allows the end user to choose what they want to use.

Its good for all, and I'm sure there is a 'price to pay' but if the price paid means more flexibility for KDE developers, especially application developers, and a better experience for end users by the way of choice, then I say all power to the KDE developers and the choice they made.

Reply Parent Score: 5

RE[2]: Over Abstraction?
by nzjrs on Wed 7th Feb 2007 10:36 in reply to "RE: Over Abstraction?"
nzjrs Member since:
2006-01-02

[Layer]
[Layer2A][Layer2B]
[Layer3A][Layer3B][Layer3i]
[Layer4]
[Layer5]


Layer2A and Layer2B both have limitations, personally my anecdotal evidence suggests the Layer2B works better. However in some situations LayerA may perform better, so we should probbably keep it around.

The benefit of Layer is that if Layer3C or Layer4 was replaced by a potato or a mexican bartending robot, Layer would still function. However for the 0.6% of people who use Layer3i its good to give the users choice, why should we choose when they can!

Layerisation is good because developers can code against Layer and not worry about the situation where Layer4 could become completely unmaintained in future (like what happend that other time in $recent_history).

I suppose there is a downside to all of this, but hey, I cant see it! Layer away I say!

note: comment not meant as insulting to KDE in anyway, merely a humorous observation

Edited 2007-02-07 10:39

Reply Parent Score: 4

RE: Over Abstraction?
by nzjrs on Wed 7th Feb 2007 10:16 in reply to "Over Abstraction?"
nzjrs Member since:
2006-01-02

Could not agree more, to quote Lennart Poettering, the developer of the Pulseaudio sound server.

Amarok on Phonon on GStreamer on ALSA on PulseAudio on ALSA?

p.s. you can check out the slides and video of Lennarts talk at LCA at [1][2]. I think it is more important to get a good sound server that it is to throw another level of abstraction on top...

[1] http://0pointer.de/public/pulseaudio-presentation-lca2007.pdf
[2] http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/211.o...

Reply Parent Score: 4

RE[2]: Over Abstraction?
by aseigo on Wed 7th Feb 2007 11:01 in reply to "RE: Over Abstraction?"
aseigo Member since:
2005-07-06

> on GStreamer on ALSA on PulseAudio

or it could simply be "on PulseAudio", which would reduce the chain to one applicaton using one API to one media server to one hardware interface (iow, one of "each"). you're right that it's possible to do silly things if one tries, but it's also possible to do moderately sensible things.

i'd also note that lennart's example is slightly fallacious because right now amarok already has its own backends, which is to say it has it's own "phonon light" if you will. as do each of juk, kaffeine, kmplayer. .... and they still vary in quality and portability. this isn't because the app developers like this insane duplication of effort but because it is the best solution they have found for the real world that their users live and operate in: the one where there is no One True Solution. so his "amarok on phonon" rather misses the point that it already is that way. what phonon does is it limits the number of bifurcation points to and consolidates effort into a common library for all kde applications.

> I think it is more important to get
> a good sound server that it is to
> throw another level of abstraction on top

the article notes both the orthogonal nature of these two items as well as the reason for an API on top of the native media systems (or maybe you think we should all be writing XLib apps? =).

that said, in his slides he misidentifies phonon as a low-level API among other gaffs. he is right that media on linux is a mess; what lennart didn't cop to is that right now pulseaudio is part of that mess (which isn't to say pulseaudio is a mess, rather it's part of a holistic mess). it may end up being The One True solution some day (though i'm not endorsing it as such either =), but currently it's just one more competitor in the race. well, on free operating systems anyways; it's not a serious competitor on windows or mac os (yes, it runs on windows, but it's hardly the preferred interface there is it?).

phonon divorces application code from all that chaos and limits it to one place in the code base for all apps: phonon engines. all while bringing a sane, simple and documented API for those who'd like to add some media to their app but don't want to become a media expert.

all in all this seems far more sane than trying to bet the farm on any given engine by writing directly to it; been there, done that with aRts. and if you say "oh, but aRts wasn't good enough..." i might remind you that it was the best thing of its day all those years ago; i'm going to go out on a limb here and suggest that maybe, just _maybe_, we haven't seen the end of the evolution and convolution of multimedia on linux (ignoring the non-linux platforms here for a moment for added simplicity).

with phonon we can allow that process to occur without it being overly painful for our users, operating system vendors or application developers.

this is apparently something that it seems few media server authors seem to care about given their allergic reaction to something that doesn't bias applications (and therefore users) towards their pet projects but rather allows the market to choose based on quality (along various dimensions) of the media systems themselves. it even allows them to experiment more freely as we can shield most apps from more radical changes via phonon.

Edited 2007-02-07 11:12

Reply Parent Score: 5

RE: Over Abstraction?
by martinus on Wed 7th Feb 2007 10:19 in reply to "Over Abstraction?"
martinus Member since:
2005-07-06

There is a saying among software developers: "Any Problem in Computer Science Can Be Solved with Another Layer of Indirection". This obviously is an exaggeration, but there is some truth in it.

Reply Parent Score: 1

RE[2]: Over Abstraction?
by butters on Wed 7th Feb 2007 19:01 in reply to "RE: Over Abstraction?"
butters Member since:
2005-07-08

Code imports and exports abstractions, data gets cached for reads and buffered for writes. That's how we make computers do things without introducing crippling complexity and/or bottlenecks. This is no exaggeration, this is the basis of computer science.

Reply Parent Score: 2

RE[2]: Over Abstraction?
by aseigo on Wed 7th Feb 2007 10:26 in reply to "Over Abstraction?"
aseigo Member since:
2005-07-06

gstreamer bindings do not:

- future proof our code
- make our code more portable
- make it easier for developers to add basic multimedia features to their apps

and of course gstreamer is rather more than an abstraction layer.

Reply Parent Score: 5

RE: Over Abstraction?
by MamiyaOtaru on Wed 7th Feb 2007 11:25 in reply to "Over Abstraction?"
MamiyaOtaru Member since:
2005-11-11

I don't think it's very smart abstracting the abstraction layer. Gstreamer is an abstraction layer, so why would you want to build another one on top?

"The 0.8.x series is a stable series aimed at end users. It is not API or ABI compatible with the stable 0.6.x series. It is, however, parallel installable with the 0.6.x series." - http://gstreamer.freedesktop.org/releases/gstreamer/0.8.0.html

"The 0.10.x series is a stable series targeted at end users. It is not API or ABI compatible with the stable 0.8.x series. It is, however, parallel installable with the 0.8.x series." - http://gstreamer.freedesktop.org/releases/gstreamer/0.10.0.html

Fark's sake, how hard is this to understand?

[/simple version]

Time between these announcements < KDE4's expected lifetime. With Phonon, the Phonon devs can change to adapt to a new gstreamer, and all the apps that use Phonon won't have to care. They can continue on their merry way.

An app that doesn't use Phonon but wants to support multiple applications (like amarok, say) has to make changes each time one of its target backends changes. (It's important to support more than one, since not everyone will have a particular backend. I don't have gstreamer for example). The more you want to support (to be able to be used by the most people) the more often you'll have to change.

Using Phonon lets you support all those backends without having to worry about them. Phonon gives you a stable API, and ties into multiple backends for you. You no longer have to care about which ones you will make use of.

[/brevity impaired version]

Reply Parent Score: 5

RE[2]: Over Abstraction?
by stuhood on Wed 7th Feb 2007 20:00 in reply to "RE: Over Abstraction?"
stuhood Member since:
2006-07-11

Do you really think that Phonon's API will be able to remain stable? That they will get it exactly right the first time around?

I think that might be possible... if you are willing to wait 2 or 3 more years.

Reply Parent Score: 2

RE: Over Abstraction?
by segedunum on Wed 7th Feb 2007 14:39 in reply to "Over Abstraction?"
segedunum Member since:
2005-07-06

I don't think it's very smart abstracting the abstraction layer. Gstreamer is an abstraction layer, so why would you want to build another one on top?

Have you seen GStreamer's so called abstraction layer? You're not really abstracting anything. From a programming perspective it's not exactly very nice nor does it fit into KDE programming-wise very well, nor does it future proof things or is portable in a way which satisfies KDE.

I'm generally not in favour of too many abstraction layers either, but I think the KDE people are dead right here. At least they've been able to list some hard and fast reasons as to why they're doing it, and they're all ideal reasons why you'd want a decent abstraction layer - portability, binary and API compatibility, future proofing, better and more consistent API etc.

Also in the article it mentions about implementing other backends. Isn't this just duplicated effort?

Many people mistakenly believe GStreamer to be the fountain of multimedia on Linux systems - even a lot of its developers. In a lot of ways Xine is quite a way ahead in terms of maturity and reliability (it's all I use with Amarok), and NMM is way ahead in terms of the 'next generation' multimedia things you can do with it. In short, I don't find GStreamer to be particularly compelling or worthy of the attention that gets thrown on it.

Gnome may have thrown its towel right in with GStreamer, but I think it was a wise decision to look at what requirements KDE had of a multimedia backend, learn from history and not tie itself down. Even if they were going to tie themselves to something like GStreamer, Phonon would still be relevant in terms of providing a good KDE style API and binary compatibility.

Edited 2007-02-07 14:40

Reply Parent Score: 5

RE: Over Abstraction?
by dumbkiwi on Wed 7th Feb 2007 19:05 in reply to "Over Abstraction?"
dumbkiwi Member since:
2006-01-02

You forget that kde4 is going to be available for Windows and Mac. One benefit of this level of abstraction is that kde developers can write to one API across all three platforms.

Reply Parent Score: 1

RE[2]: Over Abstraction?
by agrouf on Thu 8th Feb 2007 11:24 in reply to "RE: Over Abstraction?"
agrouf Member since:
2006-11-17

What about developing a DShow backend for gstreamer instead?

Reply Parent Score: 1