Seems Lennart started a bit of a debate with his Linux Sound layers blog post. Not all the reponses has been as enlightened though. For instance Aaron Segio managed to make me laugh with his argument for why Phonon was a good alternative for non-Qt applications:
“Phonon is also more than just an option for Qt apps: you’d be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer..”
Really? Wow, I would never have thought that if you use something instead of the other you wouldn’t need the other…an absolutely brilliant deduction. While we are at it lets point out that if you install Firefox you do not need to install Opera, cause you already got a web browser!!
GStreamer is already used by cross platform applications such as Songbird and SyncTV. And Songbird is using the native codecs provided by DirectShow and Quicktime where available.
So in a celebration of self serving arguments: So if you just use GStreamer you get equal and native support on Windows and Mac as well without the user having to install, say, Phonon…
:-)
I really don’t think that the argument can be reversed that easily.
First, Phonon lets the user/distro/sysadmin choose his preferred backend. Since the user already has a multimedia framework installed, Phonon will let him use it instead of potentially requiring him to install another framework. This is relevant because Phonon is much smaller than a multimedia framework, and also because for many reasons it may matter to the user to be able to use his preferred mm framework (unification of configuration, etc).
Second, for many app+platform pairs, a multimedia framework like gstreamer is redundant. On Windows and on Mac, the native libraries are enough for the needs of many apps, so gstreamer is not needed for them (of course gstreamer is useful for more serious audio apps but these are not the majority).
@Benoit Jacob:
And would be the difference to depend from Qt from depend from GStreamer?
None, Actually to me is more atractive depend from GStreamer than the bloated Qt. Simple as that.
@David:
Comparing size or “bloatedness” of Qt versus Gstreamer is really comparing apples and oranges.
That said, here are some numbers (Qt 4.4, Phonon trunk, release builds, x86, linux):
Phonon: 340 KB, depends on QtCore, QtDbus, and QtGui
QtCore: 2.2 MB
QtDbus: 440 KB
QtGui: 9.3 MB
Is that what you call bloated? For what it does?
Sorry but I think you had a comprehension problem here. When Aaron says
“Phonon is also more than just an option for Qt apps: you’d be making a huge mistake not to use it. You see, Phonon gets you equal and native support on Windows and Mac as well without the user having to install, say, GStreamer.”
he’s clearly talking about Qt apps, so your comparison with Gstreamer and web browsers does not really hold. Aaron is simply saying that if you program in Qt and need sound you would be really silly to use something else than Phonon to do the job. Just like your first option to connect your app to a MySQL db would be to use the facilities provided by Qt (you wouldn’t want to call, say, the C interface of MySQL directly). There’s nothing wrong in what he said.
“While we are at it lets point out that if you install Firefox you do not need to install Opera, cause you already got a web browser!!”
This is not even the same thing, Christian. Phonon is not in the same space as GStreamer: Phonon is an API to GStreamer .. or Direct* or Quicktime or xine or …
The benefit you get from using Phonon is that you don’t have a hard dependency on any one multimedia system *and* you get a familiar API to work with.
So even if ultimately the app uses GStreamer, Phonon hides that from you.
On windows and mac this does actually matter as it is then up to the user to decide what to use, and like it or not most aren’t using GStreamer on those platforms. In any case, it shouldn’t be the application that dictates that decision: it should be the system integrator.
For Qt apps, you already have Phonon around .. and it’s guaranteed to work with what’s there. If you write to gstreamer, not only will you have Qt you also have to guarantee you have gstreamer.
See how that works?
So … who is making the silly argument, again? mmmm …
@Benoit Jacob
Then comparing GStreamer and phonon is also comparing apples with oranges, phonon ain’t nothing more than a layer for audio backends, Trolltech developed the backend for GStreamer,mac and Windows, any new OS or audio system that want’s to be used from phonon would need someoned to make the phonon backend first, any cool new feature that comes out in an audio system be it in Linux or mac or windows, someone would need to updated the phonon backend first to use it, if no one updates the backend it doesn’t matter if the feature exists.
GStreamer is a complete audio solution that can stand by its own, that independence make then add many good things native audio backens doesn’t have and is also multiplatform, so you can do what phonon can and more, since phonon has the limitant to offer the same functions for all its backend it won’t offer more that some basics needs, nothing pro. this is something GStreamer get is better.
So phonon apart from have the Qt dependency (something that provokes shiver in my self and makes me say ewww) is limitatd, GStreamer is more clever.
So still GStreamer offers more and is not GPL and you don’t have to buy a license from TrollTech eather, as you can see GStreamer win hands down. period.
The benefit you get from using Phonon is that you don’t have a hard dependency on any one multimedia system *and* you get a familiar API to work with.
You keep on missing the ridicule of your argument again and again: Phonon doesn’t ship with all platforms so whether the app depend on gstreamer or phonon, it doesn’t really matter.
Implicit in your argument(s) is that Phonon provides some kind of magical high-level abstract API that can abstract many different media frameworks. Last time I checked, the api was pretty much on the same level as that of GStreamer. Corrections welcomed but please do point to some specifics.
If gstreamer wasn’t portable (which is hardly the case as pointed out in the comments on Lennart’s blog post) your argument might have had some weight.
@David: to state the obvious if you’re already using Qt, the GPL licensing of Qt doesn’t matter one wit in the decision making process. moreover, bleeding edge features in media layers like gstreamer are irrelevant for 99%+ of applications that will make sounds, play music, show video, etc. and if i need to choose between a specific media engine that realistically is not available everywhere with a foreign looking API vs an API that feels at home with the rest of my dev tools and will use whatever media system is available where my app runs .. guess which one sane developers will choose?
it’s rather obvious that for Qt applications that aren’t aiming at pro audio tools, Phonon is absolutely the right API fit.
now… you say, quite rightly, that Phonon is an API on top of the media layer (so not the same thing at ll) and then go right back to comparing them as if GStreamer and Phonon are mutually exclusive (“GStremer wins hands down. period.”).
but consider: with Phonon-GST, we’ve delivered thousands of new GStreamer using apps without the GStreamer guys lifting a finger (they started but never finished a Phonon backend). but because some people who are fans of GStreamer can’t seem to get beyond some odd API envy issue, that fact isn’t being appreciated for what it is. for some reason Phonon is being seen as a competitor, a threat. that is so amazingly incorrect it’s head spinning.
if people backing GStreamer were smart, they’d be doing what it takes to increase the technical and social bonds between GStreamer and higher level APIs like Phonon and the people behind them. they’d recognize Phonon as one more step towards their own world domination rather than taking opportunity to alienate such efforts.
Something to think about …
@Zeeshan: ok, let me try it this way:
Phonon comes with Qt4.
GStreamer doesn’t.
If your app uses Qt4, which one is guaranteed to be there?
Answer: Phonon.
“Implicit in your argument(s) is that Phonon provides some kind of magical high-level abstract API that can abstract many different media frameworks”
Well, yes. That is *exactly* what Phonon is. It’s a high level abstract API with backends that bridge the Phonon API to whatever medai framework is there. Currently there are backends for GStreamer, DirectShow, Quicktime (Mac only), libxine, mplayer and vlc.
Which makes this whole conversation all the more absurd, if GStreamer is around Phonon can and will use it.
If you doubt any of this, I welcome you to look for yourself:
http://websvn.kde.org/trunk/kdesupport/phonon/
What if i don’t want to use gstreamer? Then i have to hope that application supports something i want to use.
It looks like its easier to update phonon to use a new sound system then to update all application.
@Jonathan: What if you don’t want to use Qt? .. It’s also pretty easy to write gstreamer sink/sources for various other systems….
Also, I could point out that Qt/Phonon with its GPL license issues makes it very hard to support legal DVD playback or other licensed codecs.
Phonon is a simple wrapper that just works and GStreamer is a huge library that has a dependency graph as long as my arm, and is a pain in the backside to compile and distribute on any platform.
Seriously, these things matter to those of us who do develop cross platform applications.
Think of it this way…Songbird uses GStreamer on Linux, yes. And on Windows Songbird uses…whatever Windows uses.
But I’m certain the Songbird developers either had to specifically code each implementation (Win32 sound and Gstreamer sound) separately, or they had to make an abstract audio backend to support both — and they’ll have to repeat this step for every platform (including OS X) they port Songbird to.
Now let’s say Songbird was made with Phonon instead. Guess what? On Linux, it uses Gstreamer. So when they’re ready to make a port to Windows, Phonon will hook up with whatever Windows needs. They can even do a port to Mac OS X – bam, instant sound support.
They didn’t need to worry about if Gstreamer even worked on OS X, even though that’s the engine they prefer — if it’s available, Phonon will use it. They didn’t need to worry about coding specifically around _any_ audio API. They didn’t have to reimplement their own audio backend on each platform (or worry about how well GStreamer works on Windows versus Win32 native audio). Phonon uses whatever will _work_ on that platform.
Does no one see any merit in that kind of abstraction?
@Aaron
“to state the obvious if you’re already using Qt, the GPL licensing of Qt doesn’t matter one wit in the decision making process. ”
But if aren’t already using Qt then you are kind of screwed, since you are trying to sell phonon for not only Qt applications but in general this “litle” licensing question arise, actually, arise for all KDE libs depending of Qt in general, so please, don’t try to minimize the licensing issues, it is big.
And is not being a fan of GStreamer the issue, the issue is if you are want to make use of a multiplatform API that is not Qt based then forget about phonon, simple as that, of course if you have no problems with the license then go ahead and use it.
As a matter of desition phonon is isolated because its use of Qt, it has been always like that for KDE in general, but looks like you guys had learned the lesson with strigi, but is to late for it, there are tons similars like it now.
So I hope the next time you base your desition to make a library beyond of KDE, discart Qt inmediatly.
David,
You seem very unreasonable.
KDE/Qt embraces tons of GNOME related libraries, of which GStreamer and GLib are just a few examples.
I completely miss the point of the GStreamer people attacking Phonon so vigorously.
If you’re a software developer and you choose Qt as one of the libraries to develop with, it makes all the sense in the world to use Phonon instead of GStreamer or Xine directly. It saves you months of work and bugfixing not to mention the cost that comes with that. That’s even without porting to other systems, which you get for free with Phonon.
In all, it doesn’t matter if it is Phonon. It’s the idea behind it.
If you think you can write a similar library using GLib or whatever, without Qt, then by all means, that would make it a competitor to Phonon and a pretty good choice too above GStreamer, Xine, etc…
@Jud
Then it is obvious SongBird developers didn’t want to depend of Qt at all, don’t you think?
@Jud: You seem to be missing that GStreamer does “do sound”, its a plugin based system. So on linux we have plugins for pulseaudio, alsa, oss and on windows there are plugins for directsound (and directdraw too) and on OSX for osxaudio and on maemo (<5) for their dsp stuff.
GStreamer already offers a platform abstraction (and much more), and when used over Phonon, you have an abstraction above another abstraction. And I think that’s what most non-Qt/KDE people find ridiculous. Especially considering that Phonon does much less than Gst.. (There is no way you could do something like Farsight with phonon..)
@tbscope
“If you’re a software developer and you choose Qt as one of the libraries to develop with, it makes all the sense in the world to use Phonon instead of GStreamer or Xine directly.”
I won’t argu about that, but trying to sell phonon beyond Qt applications it is simple ridiculous, I know is Aaron’s job to try to sell Qt liceses but the guy simple needs a reality check.
@David: could you please try to keep an adult discussion? Your personal attacks to Aaron and your fobia against Qt are realy bored.
This is an interesting thread and I want to read well based opinion; your interruptions are really distracting.
(Sorry for my bad english.)
David,
“I won’t argu about that, but trying to sell phonon beyond Qt applications it is simple ridiculous, I know is Aaron’s job to try to sell Qt liceses but the guy simple needs a reality check.”
Well, Aaron is not selling Phonon or Qt. He’s selling the idea behind Phonon.
I’m sure he doesn’t care what you use in the end.
What he does care about, and me too, is the misinformation spread about Phonon (or similar API’s).
To David:
Exactly. :) So there is a flaw in the argument. If Phonon simply wasn’t tied to Qt, that alone might just double it’s usefulness. So that will definitely limit it’s use. But the idea of a cross-audio-API API (that’s a strange term, alright) isn’t a horrible one.
To Tester:
I’m aware that GStreamer does sound. That’s not the point. Phonon doesn’t “do sound”. It does “do sound systems.” In addition, it won’t be dumb enough to use Gstreamer’s wrapping of Win32 on Windows. You’re right, a double wrapper would be absurd. That’s why it does Win32 directly, like Gstreamer. (At least I hope it won’t be that dumb. Goodness, I could be wrong, seriously. That would be tragically dumb on Phonon’s part.)
So you say, what’s the benefit? And that is — you’re not concretely tied to a specific audio API. GStreamer’s wrapper/port may have bugs on Windows. Phonon would never notice GStreamer’s bugs, since it would just use plain Windows on Windows.
You’re right, there is some duplication of wrapper functionality. But overall, Phonon’s approach (by abstracting the wrappers away from a _single_ library) is more useful and flexible to developers than a mere Win32 GStreamer port alone. (If only Qt didn’t always come attached.)
Come on! Give Aaron Seigo a break he is just a loyal Trolltech minion doing his job. you know.. telling everybody to love another abstraction to the abstraction. This way Trolltech can easily bundle DRM with linux and make the profitssss they havent seen the last few years.
Tasteless.
@tbscope: “I’m sure he doesn’t care what you use in the end.
What he does care about, and me too, is the misinformation spread about Phonon (or similar API’s).”
exactly.
@bonobos: what DRM is this that you speak of?
bonobos: afaik trolltech never made a lot of profit, especially not in the recent past.
@Tester: “I could point out that Qt/Phonon with its GPL license issues makes it very hard to support legal DVD playback or other licensed codecs.”
Phonon doesn’t do any decoding or codec handling. it is a media API, nothing more. supporting legal DVD/mp3/etc codecs is an issue for the operating system’s media framework to deal with.
Phonon comes with Qt4.
GStreamer doesn’t.
No shit! That is because you decided to put a wrapper on top of GStreamer (of which you didn’t have an equivalent of in KDE world, surprise surprise) and making it part of Qt. You could have just made GStreamer a part of Qt instead (not saying an integrated part of course) and everyone would have lived happily ever after. As Tester pointed out GStreamer provides nice abstraction already by the help of plugins so you can provide different implemenation of sources, sink, codecs etc etc on different platforms.
If you doubt any of this, I welcome you to look for yourself:
http://websvn.kde.org/trunk/kdesupport/phonon/
Look for what exactly? I already knew what Phonon claims to be but I asked for specifics to see if that really is the case. i-e Which API/functionality does Phonon provides that GStreamer doesn’t?
@Zeeshan Ali
“You could have just made GStreamer a part of Qt instead (not saying an integrated part of course) and everyone would have lived happily ever after.”
So true, and what is botter me is when some one make a multidesktop and independent abstract library, this guy (Aaron) will spread his well know FUD telling how that is a duplicated work and how they should have joined them to work with phonon.
I think Colin Guthrie had hit the bull’s eye in his comment on Lennart’s original blog entry: http://0pointer.de/blog/projects/guide-to-sound-apis.html
@Aaron Seigo Are you telling us Trolltech would never do such a thing? For what other reason would they aquire copyrights for phonon?
@bratarsch You are right, Trolltech havent had any economic succes lately. That is why you should fear them. The dont give f*ck about phonon, gstreamer or what ever. They just want to sell locked down sh*t to customers building stuff like the netflix player.
Aaron Seigos mission right now is to inject a Trolltech-controlled project as an useless abstraction to the abstraction. At least Darle McBride was being honest and up front when he was crusading against freedom.
Someone already pointed it out and it seems no one bothered to read it, but Aaron as far as I understand isn’t advocating non-Qt applications to use Phonon like a lot of people here misunderstand. What he is saying is that if you use Qt, there is no reason not to use Phonon (unless what you want to do isn’t supported by Phonon, which isn’t the case for 90% of the applications).
@Zeeshan: “That is because you decided to put a wrapper on top of GStreamer”
no, it’s a wrapper on top of media systems. GStreamer is one of those.
“of which you didn’t have an equivalent of in KDE world, surprise surprise”
so … you’d be happier with a NIH solution? i really don’t get your reasoning. we opted to make KDE4 media framework portable. we are not a media framework project, we are an application framework, desktop workspace and graphical applications meta-project. should we also write our own operating system kernel? our own xserver?
and yeah, you really don’t want to open the pandora’s box of “things the KDE world has that other FOSS projects haven’t gotten to yet”. i won’t go there because it’s ultimately destructive to our shared community, but if we *were* to put all the cards on the table and compared things your “surprise, surprise” comment would look pretty stupid.
“You could have just made GStreamer a part of Qt instead”
been there, done that with aRts. remember that when KDE 2.0 came out, aRts was the GStreamer of its day. seriously.
“and everyone would have lived happily ever after. ”
those pushing for gstreamer hard might have been happy ever after, sure. those wanting a Qt style API or wanting to use something other than gstreamer on their machines wouldn’t’ve.
and i do have to wonder why people push gstreamer, which works with phonon just great and which does nothing to diminish gstreamer in any way, are so agressive in pushing their solution in the fashion they do. there’s a lack of grace inherent in those arguments that makes one wonde. you are doing gstreamer a *disservice* with the negative approach that is so evident here.
“Which API/functionality does Phonon provides that GStreamer doesn’t?”
a Qt-style API that doesn’t rely on one particular media framework implementation. this gives me the ability to throw video onto my app’s canvas with about 5 lines of familiar looking code that i know will work everywhere, always. (assuming available codecs of course =)
@Zeeshan Ali:
>You could have just made GStreamer a part of Qt instead
>(not saying an integrated part of course)
>and everyone would have lived happily ever after
No! You’re completely missing the point. See my first comment here.
For 95% of apps, on Windows and on Mac, Gstreamer is completely redundant since the native libs (DirectX etc) do the job. So having a thin wrapper around them is all what you want. Phonon plays that role. For example, Amarok on windows works like this:
Amarok->Phonon->DirectX
what you propose instead is
Amarok->Gstreamer->DirectX (or whatever sink gst uses).
This is functionally equivalent… but bigger.
Now there is yet another good reason to use an abstraction layer like Phonon, it’s ABI compatibility, see Michael’s very good explanation here:
http://lwn.net/Articles/183462/
It’s really sad that 2 years later Gstreamer people still hate Phonon that much. Phonon is just a library that sits downstream of Gstreamer.
“You could have just made GStreamer a part of Qt instead (not saying an integrated part of course) and everyone would have lived happily ever after.”
Yeah but gstreamer isn’t or wasn’t thought of by Qt/KDE so it was rejected. For some reason that camp seems to have to re-write everything the Qt/KDE way. They have no desire to use anything other than what crap they dream up, hence plasma and the ruination of KDE4. Give it up already Qt/KDE is a sinking ship.
@bonobos:
> Are you telling us Trolltech would never do such a thing?
> For what other reason would they aquire copyrights for phonon?
Get your facts straight before commenting!!
Trolltech didn’t acquire the copyrights of Phonon. Instead, they did the absolute best thing: they agreed that Phonon would continue to be developed in KDE’s SVN, see for yourself,
http://websvn.kde.org/trunk/kdesupport/phonon/
you can check the copyrights, they still belong to the individual contributors to Phonon. See the source files, for example
http://websvn.kde.org/trunk/kdesupport/phonon/phonon/abstractaudiooutput.cpp?view=markup
“You could have just made GStreamer a part of Qt instead (not saying an integrated part of course) and everyone would have lived happily ever after.”
Isn’t that exactly what they did? Of course, to make the KDE developers happy, they added a high level abstraction layer on top of it. Then, they ported it to use the Windows/Mac sound system directly, so that they weren’t wasting resources with unnecessary abstractions on those platforms.
The comments here are really disappointing, I thought that the open source community had grown beyond this sort of petty demonizing of other frameworks.
Guys I found this in one of the comments to Asiego’s blog: http://lwn.net/Articles/183462/
It is from someone named Michael Pyne. And it is the first piece I have read about the Gstreamer vs. Photon issue which is not FUD and appears not to be based on misinformation. According to this text the *real* issue is binary compatibility-ie. that Gstreamer cannot and will not provide the ABI stability that KDE4 needs for the length of KDE4 lifespan, and not through any fault of their own.
According to this text the binary compatibility is the key issue here: in his own words:
“This isn’t to blame the gstreamer developers: Both gstreamer upgrades were a definite change for the better. But the problem is that they were still a definite change. We won’t be able to keep the Qt/KDE gstreamer bindings up to date, not to mention binary compatible, without limiting the scope of the API that we wrap. In fact, Phonon is about the extent of the amount of wrapping we’d be able to do.”
It seems to me that phonon is an extremely thin layer which wraps an abosolute minimum which is equally supported by all backends (directshow, quicktime, gstreamer, xine). It is a convenience API for QT/KDE app developers who do not need to do any real heavy lifting-ie. more demanding audio/video work.
You guys can go on and on about QT vs. Glib dependencies, or LGPL vs GPL, or about how good gstreamer compatibility is acrosss various OS’s-but if KDE needs binary compatibility for the life of KDE4 and phono fills this bill then it is the best tool for the job.
Of course what would be really cool is if Nokia/trolltech would simply wrap the entirety of gstreamer and place it directly into QT. Then QT/KDE devs would have this amazingly simple abstract API which is pure magic for those devs and they would embrace the media framework developed by and for the FOSS community. Then work could be done to soldify the OS X and Windows gstreamer ports so that really shine.
And of course what would also be really cool is if QT/KDE would wake up and smell the roses and actually address the issues which Pulseaudio is addressing. I want to see support for XDG sound themes in KNOTIFY and I want KNOTIFY not to wreak havoc with other applications vying for access to my sound card. Hey maybe if the KDE community would embrace Pulseaudio there might even end being good ports of Pulseaudio to other OS’s ;) And I want that when I use a KDE multimedia app that it registers itself with Pulseaudio and lets me redirect my audio to my PC connected to my home surround sound system.
Put another way it simply would not hurt QT/KDE to embrace gstreamer and pulseaudio and to do so publicly. Many act as if these two projects were GNOME projects-the reality is it is the distros which have made their interests clear-gstreamer is *the* FOSS media framework and pulseaudio is *the* FOSS sound server. This is not a GNOME vs. KDE thing-it is a KDE-runs-on-every-platform-under-the-sun-aspiration vs. Linux distributions. The linux community via gstreamer and pulseaudio is finally beginning to really address some its real shortcommings and
KDE is off touting Windows compatibility…major disconnect here…
And in the meantime we will just ignore the fact that most users don’t care about the legal obligations of the commercial corporations involved in gstreamer development and the commercial corporations involved in Linux distribution-us users will simply install xine and mplayer to deal with those things which gstreamer cannot deal with or only deal with by demanding outrageous sums of cash. At least KDE devs give us the choice to use xine-something the GNOME devs don’t do(ok I lied: totem-xine is still around ;)).
iwbcman: thank you for the most reasonable comment here so far, amid the tribal chest-beating and clearly wilfull misunderstand of words and intent. It is amazing that nobody in the course of this discussion mentioned the efforts that mpyne and others made in adopting gstreamer, since at that point it really was looking like gstreamer would become, lock stock and barrel, _the_ media api for KDE.
While it is a shame it didn’t work out at that point, the Phonon situation was going to happen in any case, considering the stylistic and syntactic dissonance that would come from coding with a mix of Qt/C++ and gstreamer/C in apps that required even the most basic “just play this audio file and don’t bother me” case. All that has happened is that 1) the API became more general so it could use an implementation other than gstreamer and 2) the impl became pluggable instead of a compile-time dependency (anyone who has even a passing familiarity with KDE development shouldn’t be surprised by this – Qt makes it easy and different types of plugins are popping up everywhere). Absolutely nothing has been lost, but KDE developers who are not writing hard-core media apps got a simple, non-surprising API to work with without having to worry about backend or platform details.
Looking at it from Trolltech’s perspective: these guys are selling a toolkit that is not just for KDE but for every platform and device, so its no wonder that they hired the Phonon developer to make it as flexible as possible. Whether or not desktop linux distros end up shipping only the gstreamer backend is irrelevant here.
Asiego you just said:
““You could have just made GStreamer a part of Qt instead”
been there, done that with aRts. remember that when KDE 2.0 came out, aRts was the GStreamer of its day. seriously.”
Exactly what flavor of crack inspired that particular comment?
I can understand if you are pissed off at the Gstreamer developers but that is a really, really low blow. aRts was never any kind of multimedia framework and you know it. It never enjoyed any kind of success beyond the ultra primitive multimedia support which KDE offered for the first years of it’s existence.
Calling aRts the Gstreamer of it’s day is 1) totally disingenuous 2) factually wrong 3) outright facetious. If you were comparing aRts to Pulseaudio you might, just might have 1 plus point for a valid comparison and only -10 due to the fact that Pulseaudio does far more, and is far better than aRts ever even aspired to be. But you are comparing aRts which was primarily a one man job(Stefan Westerfeld) and which was abandoned when it was no longer being maintained to one of the largest and most diverse and longest-running FOSS communities around-one that has given birth to multiple commercial interests, and the only comprehensive multimedia framework in existence in the FOSS world(I do not count xine, mplayer/mencoder, ffmepg and friends as a comprehensive multimedia framework-they are good tools for specific tasks-and I am not counting Helix which to date has seen practically zero uptake).
QT/KDE has offered nothing to the development of a FOSS multimedia framework except wrappers around the work others have produced-and that is fine and good for KDE app developers but does nothing to redress the missing functionality in the FOSS world. You may argue that this is not your job or the responsibility of Qt/Trolltech/Nokia. But by not embracing the projects which this FOSS community develops you weaken the strength of these projects and their uptake in the broader commercial world-united we stand divided we fall.
You lambasted Lennart for commenting about things he is not familiar with-that comment from you is either completely disingenuous or you are completely out of your league-my guess is that it is the former because you are usually refreshingly competent about such issues. Go ask Stefan if he views aRts as the Gstreamer of it’s day….aRts was the sound synthesizer and sound server of it’s day-Gstreamer is neither, primarily.
iwbcman: “Go ask Stefan if he views aRts as the Gstreamer of it’s day”
http://markmail.org/message/pxcdlhjvxk7fqy33
He did. But a later email a few years ago (sorry I cannot find a link right now), outlined how he felt, in hindsight, that the design for aRts was incorrect for what he was trying to do.
I think a lot of people on this thread are also missing that Phonon just does a tiny bit of what GStreamer can do, it basically only abstracts “playbin”. For something complex like Farsight (a videoconferencing library), GStreamer is basically the only usable framework (on any platform). So KDE developers who would want to integrate this kind of functionality into their applications are still at a disadvantage and really won’t have a choice but to use GStreamer directly.
I think a better approach would be a QGObject, some “generic” way to make Qt-style GObject wrappers (something similar to pygobject if you want). Then the Qt crowd could use the full power of GStreamer easily without having to worry.
please aron don’t waste your time with these people. gnome people is the same as microsoft people – spreading and spreading FUD to everyone –
these people will not understand what is a good API/library/framework in 1000 years
just don’t waste your time. let’s make KDE rocks instead of
Wow.. So little understanding.
It’s simple really, if you’re not using Qt, use gstreamer. If you’re using Qt, phonon is the better solution* because the API is consistent, integrated, and you’re not dragging gstreamer onto other platforms that have zero need for it. I can’t believe anyone is arguing with that.
* If you’re in the 1% of people that are writing a videoconferencing or audio processing app with Qt, use gstreamer.
Taj,
Cool, thanks for the link. Remember that email dates back to 2001-the Gstreamer of 2001 and 2008 are two very different beasts-not only in terms of capabilities but also in scope and aspiration.
My comment may seem to be disparaging Stefan’s work on aRts-sorry if it came across this way. aRts was good at what it was designed for-but it was never designed to be a comprehensive multimedia framework. I am sure one could argue that it is just semantics but sound synthesizer/sound server does not equate in my mind to a framework for audio and video application development.
Hmm, sorry to see that people keep fighting about gstreamer and Phonon after all this time. :(
I’m the author of the LWN letter to the editor that some of you picked up on (http://lwn.net/Articles/183462/) and I’m still trying to make gstreamer work better in KDE (http://www.purinchu.net/wp/2008/06/16/improved-crossfadiness/ and http://websvn.kde.org/?view=rev&revision=851133).
But can we please get less FUD? :) Just because KDE doesn’t directly use every existing g* library doesn’t mean we’re trying to reinvent the wheel. Many people have pointed out that Phonon doesn’t do nearly as much as is possible in gstreamer, and they are exactly right. Phonon is not designed for that usecase, it is designed to be a simple to use and implement multimedia API. KDE applications needing to do something like Farsight need to choose a backend and this has been known for a long time.
I mean, I understand that it sounds like whining if you don’t do development but I’ve helped maintain native gstreamer support in a KDE application and the difference between even a well-designed C library and a well-designed Qt-style C++ library is like night and day. And this isn’t even getting into binary compatibility concerns that I brought up years ago. Using C as your base language brings advantages, including the fact that the library can be used by practically every other language. But in our case we’ve chosen C++ so given that we’re using C++ we’re certainly not going to limit ourselves to C-style APIs.
My recommendation: If you’re designing a Qt-using application with simple multimedia needs use Phonon. This will buy you relative future-independence (for instance, should Christian and the crew decide to release gstreamer-0.12 all that is needed is one new Phonon backend and not dozens of gst-0.10-using applications to be ported). In addition if disaster occurs and gstreamer is not supported or poorly supported on a system it is still possible to use alternative backends such as Xine.
If Phonon does not fit your needs or you are not using Qt, it is best to use gstreamer directly. The risk of API breakage is low anyways as the 0.10 series is still in use, so it’s obvious that the API changes have quieted down. Other competing APIs such as Xine may have better compatibility but I think it’s clear that gstreamer’s design makes it more generally useful for multimedia applications. The C API is a turn off to me but if you’re willing to use a wrapper like Phonon then gstreamer has other good wrappers I’m sure for e.g. Perl and Ruby. If you mix C++ and gstreamer just don’t forget to always cast 0 (as in the null pointer) specifically to void* in glib-style variadic functions otherwise you’ll break 64-bit apps. (If NULL is defined as something like (void*)0 it is safe to simply use NULL).
One final thing: @iwbcman, aRts actually was designed to be a comprehensive multimedia framework. It included audio, a sound server, video support (although typically b0rken due to crappy codecs or drivers or something in my experience) and even it’s own communications IPC mechanism designed for high speed IPC. If it were really super simple KDE developers would have been able to maintain it I feel, as it wasn’t simply from lack of interest that aRts bit rotted. If I remember right it even came with a GUI application for plugging different multimedia modules into each other, called artsbuilder.
@iwbcman:
You can use pulseaudio as outputdevice for Phonon and should be a happy camper.
@iwbcman: I think you’re taking the comparison a bit more literally than it’s meant.
“For instance Aaron Segio managed to make me laugh with his argument… ”
Ironically, as someone who actually understood what he wrote YOUR comment made me laugh, because you completely missed the point.
“They have no desire to use anything other than what crap they dream up, hence plasma and the ruination of KDE4. Give it up already Qt/KDE is a sinking ship.”
That is so ridiculous i can’t even find words for it. Please please have a look at the history of desktop environments on Linux! Also, about the fdo projects all of the gnome community seems to praise, have a look at DBUS in comparison to DCOP and CORBA and see which is more similar.
@Aaron: repeating that you didn’t include GStreamer in KDE because you’ve ‘been there, done that’ with arts gets old about as fast as people claiming they prefer GNOME over KDE because ‘GNOME is more free’.
The problem with arts was with arts, and it’s unfair to cite your problems with arts as a reason not to use GStreamer. It’s good to avoid making the same mistakes again, but you don’t do that by doing things completely different just to be different – you do that by figuring out what exactly went wrong and fixing those things.
There’s just no way you can compare the development community that arts had to what GStreamer has.
@bonobos and @bratarsch: let me follow your trolling and FUDding and let me respond you with a couple of questions. Does gstreamer have a commercial software house behind? Do (or did) gstreamer’s creators SELL proprietary codecs for their software? Who’s the “evil” here, following your trolling practices?
But since you’re trolls and your arguments are completely stupids, my questions are just the same. (so serious people here please ignore them)