Submitted by “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.”
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!
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.
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.
This could be fixed by simply maintaining GStreamer 0.10.x forever, which is probably less work than creating Phonon and all its bindings.
You don’t know what you say.
GStreamer is at least a factor hundred more complex than Phonon.
> This could be fixed by simply maintaining GStreamer > 0.10.x forever,
and how does that address portability and simplicity of API issues? it doesn’t.
moreover, taking on the maintenance of gstreamer would be insane because it would then require that operating systems would ship our version rather than fluendo’s version, not to mention would require a kde team familiar with gstreamer and with the time to do the work.
> which is probably less work than creating Phonon
> and all its bindings
you guessed wrong. by a huge margin. =)
taking on the maintenance of gstreamer would be insane because it would then require that operating systems would ship our version rather than fluendo’s version
It would also be a support madness. Try to tell users why the codec plugins they jut purchased from Fluendo do not work while they meet obviously all requirements (having GStreamer installed)
And the distro packagers will “love” you as well, since the have to package GStreamer twice, allow installing of development files without conflict, etc.
This could be fixed by simply maintaining GStreamer 0.10.x forever
A brilliant idea. Maintain an entire version of a discontinued media library yourself (Fluendo and other GStreamer developers would have obviously moved on to the next version), with limited manpower and limited real expertise with GStreamer. The negates the whole point of utilising another piece of open source software.
Additionally, again, you’re another person who just assumea that GStreamer is the multimedia framework to use. The multimedia landscape will almost certainly look quite different in a few years, and things will have moved on. I’m not even sure what the fuss about GStreamer is even today.
Does GStreamer work on Windows? Does it work on the Mac? Does it work on *BSD? Does it work on <insert OS that KDE4 will run on>?
Wouldn’t it be great if people could write a KDE4 application using just KDE4 calls, and have it run on Windows, Linux, Mac, *BSD, etc using the native sound/widgets/etc of the OS its running on? You know, kind of like what Phonon et al will let them.
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.
[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
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…
> 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
I completly agree with aseigo. I think the presentation does not describe phonon the right way. I think that this also proofs that phonon is the way to go. Lets say that Pulse Audio ends up beign the best thing for audio in the next years then KDE would be ready to use it trough phonon. Also as I understand phonon allows Kde to do some things that Pulse is trying to do like the volume control,better network transparency and some higher -level fuctions. I think that Phonon can do some of the compiz of sounds fuction that lennart is talking about.
I think his exmple of phonon was fallacius since later on he stats that he is thinking on dogina new abstracted sound API (Phonon!!!). I like that the KDE project its not taking sides on this whole linux sound mess and are making it easier for its users on the long term. Don’t get me wrong I want this mess to be fix, but as a user I don’t want to suffer from it.
Will phonon be able automatically adopt to whatever is using sound device at the moment?
If not it unfortunately trades usability for developer convenience. And of course it doesn’t do anything to relieve current linux sound mess.
Besides KDE as in part responsible for current situation should step in and help resolving it.
It could put its weight behind one framework (both sound access and codec support) or work under auspices of OSDL towards working out one, lowlevel system wide sound api (which can later be wrapped by phonon).
Edited 2007-02-08 12:15
Will phonon be able automatically adopt to whatever is using sound device at the moment?
I am afraid I don’t understand what you mean. If you meant that it can switch between sound devices if they change there state, e.g. an USB device being unplugged, then, yes it can.
Besides KDE as in part responsible for current situation should step in and help resolving it.
It could put its weight behind one framework (both sound access and codec support)
They once did exactly this, it was called aRts. At that time the best decoding/effects/mixing solution available, desktop and technology neutral.
Since we all know how this turned out, how likely is it to believe they are going to make the same mistake again?
which can later be wrapped by phonon
I am afraid I can’t see any advantages in not having media output capabilities or waiting with KDE4 until some miracle occurs and the ultimate backend solution emerges from the void.
I, however, can see the advantage of being able to adopt to such a miracle solution in the unlikely case it would happen, while being able to play media with current solutions right now (just in case the miracly should not happen)
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.
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.
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.
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]
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.
> Do you really think that Phonon’s API will be able
> to remain stable?
that has always been our commitment for stable releases, yes. and so far we’ve done well.
> That they will get it exactly right the first time
> around?
nope. that’s why we have alphas, betas and some four million lines of code to play with, among them many applications which do or will use phonon.
if amarok, juk and kaffeine all work well with phonon and users manage to not get bleeding noses during the betas then we should be pretty close to good.
we stress the APIs before they get released and we have ways to add to APIs in ways that preserve binary compatible to correct issues. then in some number of years we’ll do a kde5 that will be a streamlining of things just like kde3 was for kde2.
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
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.
What about developing a DShow backend for gstreamer instead?
I watched the video linked from the article and well, I don’t know whether it’s a problem with video/audio synchronization, but the response time of the system to the commands issued via GUI (highering/lowering the volume, switching output device, stopping the player) looks to be way too high, almost close to one second!
Edited 2007-02-07 09:59
This was addressed in the comments – it is a bug in libxine, not Phonon. Basically, libxine ignores all the data it has already dealt with, so when you change the volume all data in the buffers remains at the old volume. A fix would be for libxine to clear the buffers when needed, but that isn’t something Phonon should be doing.
I am mainly hoping for jackd adoption to catch up. There are now plenty of multimedia studio distros around that use the integrated features that jack provides. Any plans to add jack to the list of supported backends in phonon?
ny plans to add jack to the list of supported backends in phonon?
Matthias Kretz answers this in a reply here:
http://dot.kde.org/1170773239/1170778900/
Basically “backend” in Phonon means someting that can handle encoded multimedia data, so jackd is not a candidate for a backend on its own. It can however be used as the “device” the backend writes to, if the library used in the backend has an option for this, e.g. GStreamer
Thanx for your clearing that up
……..planning anything similar to Phonon for 2.18 or 2.20?
if not, is that because they don’t need it for some reason?
or is it perhaps that they don’t have the flexibility to initiate major changes so quickly as they are not starting from scratch?
cheers
My guess is no, and I hope Gnome will stick to relying on plain GStreamer. Like most Gnome libraries GStreamer uses GObject for object-oriented programming style, which means that bindings for other languages are easily auto-generated. This means that complete multimedia applications can be developed in higherlevel languages such as Python, Java or C#.
> complete multimedia applications can be developed
> in higherlevel languages such as Python, Java or C#
your conclusion is incorrect. kde has been successfully providing python, ruby and java bindings for quite some time. several production quality apps are written in pykde for instance. the pykde/pyqt bindings are amazing in quality and features, and the ruby ones are pretty much right up there as well.
not to mention ecmascript. there’s also work on c# bindings for qt4/kde4, and then of course there’s the stupidly amazing qt/jambi java bindings.
the idea that c++ isn’t bindable is a complete myth that kde has been disproving for years with high quality bindings produced by small numbers of people that are used by real world apps.
Well I gladly admit that I have no deep knowledge of the inner workings of binding C++ to other languages, and if you guys have found a way to autogenerate bindings for other languanges thats great news.
>>your conclusion is incorrect.
it is correct, since practice says that gobject based c libs *does* make bindings generation for high level languages easier. And jkroon do not say a word about the possibility of binding with c++ being difficult because of that.
Looks like you are answering to another statement made from another person.
Edited 2007-02-07 19:08
…made *by* another person. (Engrish…)
it is correct, since practice says that gobject based c libs *does* make bindings generation for high level languages easier.
In what way, because I don’t see bindings being any less easy to produce with KDE and C++? It’s something I see dredged up time and again, and I just don’t see any evidence for it.
How do you know?
Have you tried to make bindings?
Well, I have. The steps are these:
1. Create your new library written in C using GObject’s type system.
2. Create a language independent .defs-file that describes the class-hierarchy.
3. Use the .defs-file with tools for automatically generating the language binding code. Python has one in PyGTK, C++ has one in gtkmm (I think), C# has one in Gtk#, Java is in progress.
The Java bindings for Gtk were until recently _manually_ written, in the same way I’m guessing that most of the wrappers for C++ libs are created, although I’m investigating “smoke”. Looking at it from an engineer’s point of view it should be pretty obvious which method is preferred.
How do you know?
Have you tried to make bindings?
I’ve tried out SMOKE a few times out of interest and actually found it reasonably straightforward to produce some bindings. Judging from the selection of good quality bindings that currently exist (http://developer.kde.org/language-bindings/), some of which don’t use SMOKE, I don’t see C and GObject being that much easier to bind in the way that some claim. It’s one of those things that just seems to get pulled from goodness knows where.
I’ve tried out SMOKE a few times out of interest and actually found it reasonably straightforward to produce some bindings. Judging from the selection of good quality bindings that currently exist
Yes, Ashley Winters Smoke design, originally for PerlQt, is very innovative. The Gnome guys have talked about doing something similar (eg Havoc Pennington), but haven’t actually gone ahead. It is auto-generated from the Qt/KDE headers, and the same library can be used be multiple languages so you don’t have to keep reinventing the wheel for every bindings project.
It is being actively developed to wrap Qt 4.x by PerlQt, QtRuby, Qyoto C#, and Thomas Moenicke is even working on PHP bindings using Smoke.
The word ‘easy’ doesn’t actually apply to either KDE or Gnome bindings projects and I personally wish people would stop using the word. Ask anyone who has succeeded in producing good quality bindings for either desktop, and I don’t think they’ll say they threw it all together in a few weekends, like the word ‘easy’ might imply.
The word ‘easy’ doesn’t actually apply to either KDE or Gnome bindings projects and I personally wish people would stop using the word.
No it certainly isn’t ‘easy’, but with Smoke and auto generation of some kind it’s an awful lot better to do than it would have been. You have my admiration.
I can imagine that on a wider level C and GObject might be less restrictive to bind (hey, it’s C and you can do anything!), because you don’t have the overhead of the something like the Qt framework, but to claim that it is easier because of that is a bit wide of the mark – certainly within the desktop level context we’re talking about.
You then have work to do on top of that to make those bindings something that people can actually use practically on a day to day basis.
>>In what way, because I don’t see bindings being any less easy to produce with KDE and C++?
I wanted to say “easier with gobject than without it” and nothing to do with c++ or kde or wathever.
And no, I don’t have made any bidings myself, but by intention of its creatores and the number of bindings available for GTK+, for an example of a glib/gobject based library, one can infer that is not that difficult.
> gobject based c libs *does* make bindings
> generation for high level languages easier.
if we go based on availability and quality of bindings, i don’t see the evidence for this. if binding c++ libs is harder, then it’s not so appreciably harder to hinder binding availability.
> And jkroon do not say a word about the possibility
> of binding with c++ being difficult because of
> that.
that is what was implied; read his reply to my reply for confirmation of that =)
Are you sure you didn’t miss the word “autogenerated” ?
As far as I understand, Phonon tries to do what Gstreamer does, therefore Gnome does already have something similar.
As far as I understand, Phonon tries to do what Gstreamer does
Well, no, that’s a misunderstanding.
The relations is more like an actor and a director. Gstreamer, or other Phonon backends, do the visible work, Phonon is more about coordinating things on the user’s behalf.
It is a rather simple abstraction layer which puts interfacing code into the phonon core so applications reinvent the wheel. This will allow KDE apps to run on Windows and OSX as well and it is strongest reason not not to rely on Gstreamer or any specific framework, but have phonon backend plugin for e.g. dshow or gstreamer.
No, with many competing multimedia frameworks, each supporting different codecs or having different features, Gstreamer isn’t a silver bullet, especially not for cross-platform apps.
Of course Phonon sounds great in theory, but real problem is implementation which will depend on how big differences between multimedia frameworks accross systems are. I guess applications which require advanced features will stll have to rely on own plugins and interact with frameworks directly.
PulseAudio is lower layer thing, as it actually provides raw audio playback facilities, different class from high-level frameworks (Xine, gstreamer, helix, ffmpeg,dshow…). IMO those should, where possible, have phonon backend to allow Phonon to manage lower level video & audio itself, in other words:
Amarok on Phonon on (Gstreamer,helix,xime,…) on Phonon on PulseAudio on ALSA.
> I guess applications which require advanced
> features will stll have to rely on own plugins and
> interact with frameworks directly.
that’s correct. phonon is not an appropriate solution for “professional” media apps such as multi-track studio systems. those will still need to write to a more complex API that offers more flexibility. can’t solve the world’s problems, but phonon can at least ensure the rest of the apps don’t get in the way (i personally hate how some apps use one interface, another use a different one and so you can’t run them simultaneously .. blarg!)
fortunately these are the vast minority of applications. things like amarok or kaffeine are serviced just fine by phonon, as are the more trivial examples (audio note taking, adding audio/video to slide presentations, etc). it’s interesting how few open source apps have media features, and that is attributal almost 100% to the lack of a phonon type api that is easy to write to and is realiably there no matter what OS.
Amarok on Phonon on (Gstreamer,helix,xime,…) on Phonon on PulseAudio on ALSA
Huh? Wouldn’t it just be
Amarok on Phonon on GStreamer on ALSA on soundcard
or
Amarok on Phonon on PulseAudio on soundcard
How do you get Phonon on Phonon??
siki_miki hit the main reason.
KDE 4.0 will able to run on other OSes, (OS X, Windows), so tying the multimedia capabilities to a Linux only API makes no sense.
I would rephrase that slightly, according to my understanding of things. Portability is the main reason for Phonon’s existence, but that doesn’t necessarily have to stem from OS portability. The KDE folk were burned by aRts (on Linux), and I think that they would like to avoid a similar situation in the future. Possible compatibility with engines external to Linux is an added bonus here. However, as you can find in the article, Phonon does not currently work with OS X or Windows engines.
Phonon has some really neat potential for higher level applications as well. If I understood the article correctly, codec manipulation and ioslaves should become fairly trivial in KDE with Phonon. I don’t necessarily expect these problems to disappear immediately, but I haven’t seen Microsoft or Apple completely solve them either.
I was also really happy to read about Amarok 2.0 development at the end of the article and the possibility for collaboration between both projects. I like Amarok 1.4, and the sharing of talents and experience should yield benefits for all KDE users.
It doesn’t matter whether an OS X or a Windows “interface” is ready yet. The point is as a KDE developer I won’t have to worry about. Additionally, KDE core developers won’t have to be responsible for creating all the backends. An OS X dev can make an appropriate backend independent of KDE and not have to worry about modifications to KDE applications.
Or an OS X dev could make appropriate plugins for GStreamer and not have to worry about modifying GStreamer apps.
I wasn’t trying to argue against that at all. I look forward to KDE on Windows and OS X, and I think that Phonon is a big step in that direction.
I was simply trying to express that while this approach helps KDE move to other operating systems, it is more important in solving problems across the board, and Linux is going to remain the primary platform for KDE in the near future.
siki_miki hit the main reason.
KDE 4.0 will able to run on other OSes,
Actually no, it’s not the main reason. The main reason is even more compelling.
I’ll use Gstreamer as an example. When they release the next major version(1.2 or whatever) in a about a year or two, judging from past performance it will be binary incompatible. Then KDE will have the choice to either stay with the old and soon to become unsupported version or rewrite Amarok, JuK, KPlayer, Codeine, Kaffeine, KPresenter etc. With Phonon they simply has to release Phonon support for a new backend. Letting the application developers to consentrate on writing better applications rather than rewriting for yet another API.
No, you’re missing the point.
KDE developers won’t necessarily maintain the backends.
(gstreamer, xine, etc. Although they may initially.)
This abstraction layer removes worrying about an API change in gstreamer in your example. Any KDE code will use the Phonon API which will remain fairly stable.
Of course a gstreamer API change would need a change to the backend, nothing will ever change that on any OS, but this layer means the changes are needed in the backend, not in KDE itself.
Edit: morty, i guess i misread what you said and we are saying the same thing.
People, no need to be so ticky tack over whether it is main reason or not. Whether OS or just backend portable, the idea is the same. Lets not sweat the minor details.
Edited 2007-02-07 18:37
My first thought after reading the article and comments is that this is going to be similar to the Datatypes system on AmigaOS 3.x, only with a slant towards the audio side of things on (Gnu/)Linux.
I can see the good points of arguments for and against this, but if it makes things simpler for end-users even at the expense of adding another abstraction layer, it can only be a good thing. Sound on Linux is a mess right now.
She said layers were good, so that settles it.
Serious, plusses and minuses of Layers of Abstraction
——————————————————
Plus:
Code for generic interface, get “large” things done quickly
Hide implementation details, as they may change with the winds.
Reuse already working parts, don’t re-invent the wheel (unless your Apple)
Give people who like to make line-drawings a job.
Negative:
You can’t find where anything is actually being done in the code!!
Often a steep learning curve to accomplish anything.
Buying a new pocket protector every 6 months.
That’s my $0.02
well, i wouldn’t pay 2 cents for it… i miss some good pro-points (like the ability to set global policies like ‘audio on speakers, game on headphone’ and ‘lower music volume if a call comes in on skype’) and the negative points are pretty useless. you can’t find what is done where, right, if you want a small video window + volume widget, why would you want to? the underlying media system is still there. and the learning curve of phonon will be a million times smaller than gstreamer, as phonon is way easier and featurefull for the basics, and simply omits the advanced stuff – do it yourself (you won’t need more than phonon in 90% of the apps).
pocked protector?
OK, I’ve lowered the price to $0.01.
two comments for the $0.01 is acceptable. do we have a deal?
what phonon does is basically just what amarok does now, only that it will be available for all KDE applications.
and we really need it.
gstreamer people dont like to hear it, but the fact of the matter is, gstreamer is completely unacceptable as a required dependency for kde, and for people that does not like gnome aswell. they dont appear to understand that depending on gconf, for example, is entirely unacceptable.
i for example use xine everywhere, with kaffeine, and with amarok. and the only change phonon does here is to the positive side, both amarok and kaffeine currently abstracts the backend, amarok supports many, kaffeine supports xine and gstreamer only. this code is not shared, where it may aswell be. and phonon being part of kde4 will do this, all kde applications will be able to take advantage of it.
Much of the techincal things about audio and multimedia is way over my head. What I feel like a Linux user is that there are far too many multimedia applications in Linux.
Not that I mind having a choice of different apps, it is just that there is no choice that can handle all types of multimedia. This means that I end up with two or three apps for handling different types of contents. You don’t have different mail readers to handle POP or IMAP, Thunderbird, Kontact or Evolution handles them all.
A few years ago almost all Linux distros came with three or four different text editors installed by default in the application menu, now there is just one.
The same thing should happen to multimedia software.
If all this abstraction makes it easer to create THE Linux multimedia or at least THE KDE media player, it would be a good thing for usability. To most user music is music, film is film and they shouldn’t need to know about file formats and other technical things he should just be able to open them in THE media player.
So keep up the good work.
thats not really true, you may have many players and stuff, but the major three supports it all (that being xine, gstreamer and mplayer)..
it has to be enabled by the packager though, so you may have installed a distribution with crippled multimedia, but thats not really the packages fault…
And will the Gnome guys develop a Gstreamer pluggin for Phonon?
And will the Gnome guys develop a Gstreamer pluggin for Phonon?
Quite unlikely, isn’t it? The GStreamer developers might do this, but why would the GNOME developers write something for two other projects they are not associated with?
Moreover, there are already developers working on a Phonon Backend/Plugin based on GStreamer.