Submitted by With Phonon, KDE developers will be able to write applications with multimedia functionality in a fraction of the time needed with one of the above mentioned media frameworks and libraries. This will facilitate the usage of media capabilities in the KDE desktop and applications.
It sounds nice to laypeople, but simultaniously has relevant meaning for geeks. At the same time, it’s fairly unqique. On top of all that, it’s easy to pronounce and spell! Absolutely bang-up job on the marketing!
<troll_begin
Oh great. now i can have a multimedia enabled text editor. Multimedia enabled calendar and oh gosh.
A multimedia enabled multimedia player.
</troll_end>
the headline is a bit misleading gdon’t you think. It does not make writing media applications faster… it tries to do 2 things 1) unify the approach to multimedia development 2 ) abstract hardware representation and kernel level representations to the user.
where is the “in a fraction of the time” in this ?
where is the “in a fraction of the time” in this ?
it’s in there, you just don’t see it – and you’re totally wrong about what Phonon IS.
Phonon IS about making the writing of multimedia apps easier and faster. instead of having to write (and keep up-to-date) the support for several different sound servers like gstreamer etc, you just support Phonon – which in turn tells gstreamer what to do. Phonon will have a much easier and cleaner syntax compared to gstreamer, NNM or aRts have – so its faster in itself to use, too.
and finally, if you depend on Phonon – you’ll know you don’t have to worry about binary or API compatibility, as those will be preserved during the whole KDE 4 series, and probably into the 5.0 serie.
Phonon IS about making the writing of multimedia apps easier and faster. instead of having to write (and keep up-to-date) the support for several different sound servers like gstreamer etc, you just support Phonon
Gstreamer is not a sound server …
– which in turn tells gstreamer what to do. Phonon will have a much easier and cleaner syntax compared to gstreamer, NNM or aRts have – so its faster in itself to use, too.
What does “faster to use” mean ? How can you be so sure the syntax will be easier ? And cleaner ?
Anyway, those are not the sole goals of API, and when you put such goals as easier and cleaner ahead, you can be sure doing complicated (powerful) things, which are legions in multimedia, will mean people will bypass these APIs, or will suffer using them. Besides, one more API is one more source of bugs. And don’t forget that the API has to keep up to date with its different backends.
and finally, if you depend on Phonon – you’ll know you don’t have to worry about binary or API compatibility, as those will be preserved during the whole KDE 4 series, and probably into the 5.0 serie.
Again, this is a pipe dream. I don’t say Phonon is not a good thing, but people here seem to think it has only advantages, and will be perfect.
But I see many drawbacks and recurrent problems to solve.
Phonon solves one problem : the choice of backend, meaning KDE sound system won’t have to live with a bad or deprecated one. All the other advantages cited have as many or more drawbacks.
name a few drawbacks, then.
about the API and faster writing off apps, gstreamer isn’t very well known for its clean (and keeping em stable!) API, and KDE dev’s ARE know for their abillity to write good API’s. and it’s C++, so Phonon will have a ‘natural’ advantage over Gstreamer anyway…
and still app dev’s would have to support several API’s, and offer configuration tools. Phonon will take this work out of their hands.
its also way easier to keep just Phonon up-to-date than to keep every app seperately up-to-date.
>>about the API and faster writing off apps, gstreamer
>>isn’t very well known for its clean (and keeping em
>>stable!) API, and KDE dev’s ARE know for their
>>abillity to write good API’s
What’s ugly about the Gstreamer API?
>>and it’s C++, so Phonon will have a ‘natural’
>>advantage over Gstreamer anyway…
What advantages are these?
gstreamer API might not be really ugly, but its not as clean as most KDE api’s are. well, i guess its debatable – and i don’t want to fight about it…
and about the ‘natural’ advantage, a KDE-like C++ API is much easier to use for KDE dev’s compared to a C API…
gstreamer API might not be really ugly, but its not as clean as most KDE api’s are.
Or a lot of other projects API’s, even other multimedia libraries are cleaner. As an example take amaroKs gstreamer and NMM plugins, the gestreamer one are more than twice the size of the NMM one for the same functionality.
Could they not have just integrated a C++ Gstreamer interface with Qt or whatever? Yeah yeah, it has a “G” at the start, but I believe they intended to be desktop neutral. Maybe they should have called it “DStreamer” or something
It’s just that this feels that there’s going to be duplicated effort in writing both the library and plugins, where there’s already working stuff that could be layered in with an easier to use interface.
The KDE4-related marketing is pretty good but I’m having a lot of trouble actually getting to the bottom of what the actual projects are… I can rarely find technical plans and such.
> where there’s already working stuff that could be layered in with an easier to use interface
Come on. Please read the website. Phonon _is_ an easier to use interface over multimedia engines like xine, gstreamer or NMM. It’s just that the KDE project doesn’t want to settle again on a single engine like it did with aRts for KDE3 (we know how that ended).
This should explain it in more details for you:
http://phonon.kde.org/cms/1024
And before long some people will decide that they don’t want to be tied to Phonon, so they will create yet another layer of abstraction on top of it…
that’s bull. Phonon is a KDE interface to prevent KDE apps from having to depend on unstable API’s and ABI’s. if gstreamer would commit to staying stable during the whole KDE 4 series, AND could give garantuee they’ll continue to be the best, KDE could use it. Phonon can garantee API and ABI stabillity, and as you can choose the backend, it’ll always be the best.
that’s bull. Phonon is a KDE interface to prevent KDE apps from having to depend on unstable API’s and ABI’s
That’s bull too. I thought Phonon was about protecting KDE from having to keep a buggy or obsolete sound framework.
Excuse me to make you remember that as long as Phonon is depending on unstable API and ABI, it won’t solve anything for KDE.
if gstreamer would commit to staying stable during the whole KDE 4 series, AND could give garantuee they’ll continue to be the best, KDE could use it
This is not the goal of GStreamer at all. And I wonder how an app can be guaranteed to stay the best.
GStreamer is the best currently, because it is the only one of its kind on Linux.
Phonon can garantee API and ABI stabillity, and as you can choose the backend, it’ll always be the best
I wonder. As you can’t guarantee to support all features of the backend, and as Phonon still depends on the backends, API and ABI stability means very reduced features.
> I thought Phonon was about protecting KDE from
> having to keep a buggy or obsolete sound framework.
sometimes a good solution fixes several problems all at once. phonon is a good example of this.
> As you can’t guarantee to support all features of
> the backend, and as Phonon still depends on the
> backends, API and ABI stability means very reduced
> features.
as a generic statement this makes sense. as a statement about multimedia as used in 99% of desktop apps it doesn’t.
think about what 99% of desktop applications need to do with media. open a uri, get some information on the media (e.g. metadata), play, seek, pause, stop, record, apply affects if available … it’s pretty basic and at this point in time rather well defined.
if we go to non-linear video editors or studio quality sound recording rigs, then phonon may not meet their needs and the developers of those apps may find the need to write directly to a media engine (or even OS-specific API).
but for 99% of apps it’s a well contained problem space that is 100% covered by 100% of non-laughable media stacks.
this is a good example of when thinking specifically (e.g. “about multimedia and desktop applications”) versus generically (e.g. “programming design patterns”) is helpful.
sometimes a good solution fixes several problems all at once. phonon is a good example of this.
Allow me to doubt it. We’ll see, that’s what I have to say.
I think people are overly optimistic about it.
The only problems I see solved here are those of ARTS.
think about what 99% of desktop applications need to do with media. open a uri, get some information on the media (e.g. metadata), play, seek, pause, stop, record, apply affects if available … it’s pretty basic and at this point in time rather well defined.
I don’t think media players that you describe here are 99 % of media apps.
if we go to non-linear video editors or studio quality sound recording rigs, then phonon may not meet their needs and the developers of those apps may find the need to write directly to a media engine (or even OS-specific API).
We agree then.
There are other apps that will be limited that are not non-linear video editors (like subtitle editors, conversion tools, …).
> I don’t think media players that you describe here
> are 99 % of media apps.
heh. i wrote “desktop applications” you wrote (and apparently read?) “media applications”.
media players are part of the 99% of desktop applications (not “media apps”) that phonon is designed to service. phonon is a bit of desktop infrastructure designed to provide what (surprise!) desktop apps need. media players are one of the specific use cases for the development of phonon, but not the only one.
one of the ongoing problems with multimedia development on free platforms is that the multimedia developers keep designing for production studios or simple playback while few if any have stopped to design something for -desktop application developers-. and so most of our apps that could (and should) be using sound and video are either not or doing so with far too much effort without enough effect.
> We agree then.
> There are other apps that will be limited that are
> not non-linear video editors (like subtitle
> editors, conversion tools, …).
well, this isn’t what i said, actually. what i said was advanced apps such as non-linear video editors and studio quality audio recording rigs will likely not be serviced by phonon.
as for subtitle editors and conversion tools, i’m not sure for certain (that’d be a question for matthias) but i don’t see why not.
effects are being included in phonon, for instance, and those aren’t exactly “bare bones” media features though they are requirements for a serious desktop media API. if media conversion fits that bill as well, then i’m sure it’ll make its way into phonon.
use cases first, APIs next, applications last.
Yeah I understood this part, but as far as I could tell, it’s sort of the same thing as Gstreamer is anyway. With Gstreamer you do similar things, selecting the audio engines etc. You can select a JACK, ESD, aRts or an ALSA Gstreamer sink for example.
My point wasn’t that they should have a single output engine or something, but rather that this project *seems* to be doing exactly the same thing on the same level as Gstreamer (abstracting the real audio in/out/whatever), and maybe a Qt interface for Gstreamer would have just been quicker and easier to maintain, etc.
Still.. this might be cool.. Imagine an audio pipeline that went like Phonon -> Gstreamer -> Polypaudio -> (to networked computer) -> Gstreamer -> ESD -> ALSAlib -> JACK -> audio out
Edited 2006-04-27 23:17
Gstreamer gives the option to output to whatever you want, yes. they did that to make it possible to let several engines cooperate. but Phonon doesn’t do anything by itself, it just tells gstreamer what to do. and Phonon will keep a stable (and easy to use) API and ABI, unlike Gstreamer.
> I can rarely find technical plans and such.
i’d suggest looking at mailing list archives and in our svn repositories. often these things are works-in-progress with the final design still being finalized.
I applaud the idea – it seems a lot of times these days API writers seem to forget the idea of a API is to REDUCE the code in the actual application… Some of the API’s nowadays I often wonder if I’d be better off dusting off my machine language knowledge and just going direct.
When every application that calls the same thing the same way with little or no variation ends up padded out with same 20 lines of code at the beginning (DirectX and GTK anyone?) you didn’t write your API very well…
This looks very well laid out and EXACTLY what the ‘common’ programmer should be seeing. I look forward to trying it.
That can be true. But there are things you can do with GTK that you can’t touch with a simple toolkit like say, tkinter.
It depends on what you want it for.
Edited 2006-04-27 21:56
When every application that calls the same thing the same way with little or no variation ends up padded out with same 20 lines of code at the beginning (DirectX and GTK anyone?) you didn’t write your API very well…
Absolutely! When I see APIs like that, I think “geez, just let me get to the point!” If POSIX had been designed that way, you’d have needed some 20-line magic sequence before you could use open().
If you want to see an example of the POSIX API designed that way, check out the Win32 API
The scary world of FindFirstFileEx
Phonon is not a concurrent of GStreamer. Instead, it’s a higher-level framework that can use something like GStreamer as a backend.
Phonon allows you to freely choose your backend – you’re not forced to use GStreamer. For instance, another backend will be NMM, which will be very useful for sound-over-a-network. There will also be Xine and Helix backends.
The advantage of abstracting the backend is that you’re not tied to a unique technology. You can always use the one that’s best for your needs at a given time (these things can change quickly).
Edited 2006-04-27 21:33
and amaroK with it’s multimedia engine plugins shows that it’s doable with causing lags or bloat.
hmm, is there a “out” missing next to the “with”?
This makes it much easier for kde multimedia apps to run on the windows and mac platforms. This api makes it much easier for them to use the native multimedia systems. For instance on windows Phonon could have a directshow backend and on mac, a quicktime backend.
Quote from the webpage:
The average desktop user doesn’t understand the hardware mixer. And even if (s)he does, it’s often not what is needed. A mixer that can control applications and/or application categories is what we need. So your mixer controls could look like this: Master, Notifications, Music, Video, Communication.
That would be cool. I really hate it when I have to adjust the volume constantly because different sources have inconsistent output levels. And then just when I’m listening to a CD of classical music SOME FSCKING SYSTEM NOTIFICATION BLOWS OFF MY EARS. HELLO? CAN ANYONE HEAR ME? =)
btw. whoever wrote that webpage might remove statements like
The average desktop user doesn’t understand the hardware mixer. And even if (s)he does, it’s often not what is needed.
from the section for users (although it’s doubtful that anyone who is in that group would ever read a webpage about a KDE sound api it’s nevertheless bad style imho =)
That would be cool. I really hate it when I have to adjust the volume constantly because different sources have inconsistent output levels. And then just when I’m listening to a CD of classical music SOME FSCKING SYSTEM NOTIFICATION BLOWS OFF MY EARS. HELLO? CAN ANYONE HEAR ME? =)
KDE already has a control for notification sound level …
You should have configured it long ago.
but rather that this project *seems* to be doing exactly the same thing on the same level as Gstreamer
Not exactly. GStreamer creates or processes audio data, e.g. decodes OGG vorbis streams, Phonon does not do that.
It is more like what you suggest, a KDE interface for something that provides this capabilities, just not specific to GStreamer.
Because you LEGALLY lack the most important codecs: WMA/WMV/QuickTime/Real/Flash/MP3/AAC/DVD/MP4
You can keep redesigning the transport layers until the pig can fly but if you can’t provide a way for any user to LEGALLY use the above codecs, you’re doomed. Support for ALSA, Jack, etc arn’t going to help you the least bit.
The problem with having the choice of multiple backends relies in the fact that all can’t be maintened at once, there will be ocations when the backend A is more developed than Backend B or Backend C will be droped for lack of support and at the end have one stable backend a a bunch of mediocre ones, till now, no one have talked of wich one is going to be the default, aRts, GStreamer, Xine, despite the fact of having the choice of multiple backend one must be the default, the question is wich one?, so in my very personal opinion the backend controller should be in the Qt toolkit and not in the KDE libraries.
Edited 2006-04-28 00:27
Exactly. GNOME had a similar sort of issue when it tried to be window manager independent. It refused to pick “the default” and paid the price of not being able to rely on any feature while KDE (which was optimized for KWIN) didn’t have this constraint. Eventually GNOME learned its lesson and picked Metacity as the optimized default and supported other window managers as best it could (according to the window manager spec).
> GNOME had a similar sort of issue when it tried to
> be window manager independent.
apples and oranges. window managers vary wildly in capabilities, which “standards” they implement (and how well/completely they do that), etc … because there is no policy in X, window manager vary staggeringly in their windowing concepts.
the same simply is not true of multimedia today. if you compare gstreamer to xine to nmm to the stacks on win32 and macosx to $INSERT_STACK_HERE one may notice that they all provide the same controls (play, pause, stop, effects, loading, metadata retrieval) though they implement them differently under the covers with different degrees of success and performance.
> The problem with having the choice of multiple
> backends relies in the fact that all can’t be
> maintened at once
if a media stack (nmm, xine, gstreamer) or their fans want to be able to use it in kde, they’ll maintain the backend. it’s really that simple.
at least one (and probably several) such backends will be maintained successfully (kde has to ensure that at least one is maintained, really).
but think if we banked on just -one- media stack as we did with aRts. when it becomes poorly maintained then we are terminally screwed. with phonon if -one- backend bitrots, we have others to silently switch to and rely on.
> the fact of having the choice of multiple backend
> one must be the default, the question is wich one?
this answer is probably OS specific. on K/Ubuntu it will probably be GStreamer; on LTSP i’d bet on NMM (they have pretty radical network sound requirements); on MacOS perhaps it’ll be the native sound stack; on Mandriva it might be Xine … etc.
kde doesn’t actually have to pick a default for everyone, we merely need to provide the means to pick a backend.
for those compiling from source, it may end up being whatever backend the phonon team feels is most mature being preferred and falling back to whatever happens to be installed on your system as detected at ./configure time.
There is a way for legal support for wma/wmv/quicktime…. Move to europe, use linspire, freespire… Codecs aren’t what this thing is about, therefore we’ve got gstreamer, xine…
They’re just trying not to get stuck on one program: gstreamer for example, since arts made it difficult in the past. Now you can use gstreamer, nmm, helix… whatever engine you like, it’s support to work WITh those programs, not to replace them.
My question is now, what if the Program A needs a feature the Backend B has but the user is using Backend C, and the user needs to have the Backend C becase Program D needs it?.
hmm, first plasma, now phonon. is P the new K?
introducing the new PDE 1.0!
I think you’re trivializing the API layering and not really looking at a realistic situation. We are talking about sound systems, what kind of realistic situations fit what you said?
You could be talking about codecs, and at this point both xine and gstreamer seem to run pretty much everything out there. If the backend you use doesn’t have the support for a specific codec, how is that any different than if this new API wasn’t added? Same problem.
what if the Program A needs a feature the Backend B has but the user is using Backend C, and the user needs to have the Backend C becase Program D needs it?.
In this case the user will have either Program A use Backend B and Backend C as the default or have Program D use Backend C and Backend B as default.
Your posting makes it look like there will be no option to make a different selection per application if necessary, almost like assuming only one spell checking language can be selected for all applications at a given time.
I think it should be pointed out that phonon is not for allowing the user to change backend easily. It is more of a ABI abstraction layer, that makes it easier for developers or distributions to change backends. For instance one of the issues that makes GStreamer completely unsuitable in KDE is the fact that the change ABI and API every few months. With phonon between all we need to do is exchange backends when third parties can keep their interfaces straight.
of course not all apps will be able to use Phonon! those dev’s will have to write support for one of more systems themselves (like NMM for fast networked sound, or jack, or Xine, or mplayer – gstreamer is by far not the only way to play sound, and it just became more usable then aRts with its 0.10 release. took em some time!)