Backends, Phonon, GStreamer

Thursday, May 11. 2006

Backends, Phonon, GStreamer

Chris Schaller's (a gstreamer dev) blog, as pointed out by Aaron Seigo, does pretty much miss the point. KDE has already been down the road of hitching up to the one true media framework. GStreamer simply does not offer "a believable API/ABI stability guarantee that covers kde4's lifespan." And one can't really blame it, we can't even be sure how long KDE4 will last. And portablity as well - why wouldn't KDE use the available "advanced media frameworks on other platforms" (as Schaller puts it)?

So an abstract multimedia layer is just a technical necessity for a project like KDE. However some of the issues Schaller identified are in fact real issues, ones we've experienced developing amaroK. We have an abstract multimedia backend system. One thing we've discovered is that it is very important to make sure all engines are fully functional. A user can only use one engine at a time. So an engine that is less then functional is actually quite damaging to the application - Murphy's law dictates that distros will pick the least functional backend as the default. We've considered options such as notifying the user of features that their engine lacked. But ultimately whats the point of an incomplete or instable engine when a better one exists? So a few days ago, amaroK's gstreamer engine was turned off - the Xine and Helix backends are fine, there are several open bugs on it and it does not support streaming yet. Phonon should have a similar policy of not tolerating incomplete engines.

So Schaller's points regarding the problems of having 5 different engines is one to be concerned about - however there is really no reason why Phonon has to have 5 engines and I hope it doesn't. Any additional released engine should have some justifaction (like the advanced features of NMM).

Posted by eean in eean at 13:43 | Comments (19) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Hey! I can imagine that you want fully functional backends, but I would also like to know why the other backends are better or worse!

So how about another blog entry detailing what's good and what's not so good about the various backends (from an amaroK perspective of course).

#1 Quintesse on 2006-05-12 04:21 (Reply)

The point isn't so much the functionality of the backends (GStreamer, xine, NMM..), but rather the completeness of the engine interfacing with it. Making a good engine requires constant and focused maintenance.

#1.1 Mark Kretschmann (Homepage) on 2006-05-12 04:28 (Reply)

i think thats what he meant. which of amaroks engine plugins works best at the moment? or where are the differences of the plugins, their features etc...

#1.1.1 SiberianHotDog on 2006-05-12 09:05 (Reply)

Well as pointed out in this blog, the engines that are shipping with 1.4 are all pretty equivalent.

There is an engine comparision page somewhere on the wiki, though I don't think its been updated recently.

#1.1.1.1 Ian Monroe (Homepage) on 2006-05-12 09:12 (Reply)

well, any chance that amarok's "abstract multimedia backend system" can be used as an already functional code base for Phonon?

#2 ahmed on 2006-05-13 07:08 (Reply)

I agree, I think Phonon should extract already functional code from existing project like Amarok and Kaffeine. This way we have code that has been through some testing and does exactly what KDE's multimedia apps want.

#2.1 Abdulla on 2006-05-13 08:07 (Reply)

No the API is totally different. And much of Phonon has been already written anyways.

#2.2 Ian Monroe (Homepage) on 2006-05-13 11:49 (Reply)

Hi, Nice! http://t973783est0.com [url=http://t973783est1.com]test1[/url] test2

#3 Anonymous (Homepage) on 2006-05-17 17:37 (Reply)

This isn't exactly about the post but I have beta3 of 1.4 on Dapper Drake and it wont play songs for me. I think it's because I don't have the arts engine for amarok which wont install because the version in the repos shows 1.39. Can someone tell me when it'll be updated?

#4 Kreuger on 2006-05-18 06:18 (Reply)

Why don't you use another engine like "xine"? aRts is really outdated.
If you need multichannel mixing (previously done by aRts), use ALSA's "dmix" capabilities.

#4.1 eliasp on 2006-05-18 06:38 (Reply)

There is no aRts engine for 1.4. Your post is offtopic, but if you had actually read the blog you would know that.

#4.2 Ian Monroe (Homepage) on 2006-05-18 07:47 (Reply)

Is gstreamer the only "multimedia engine" that supports monkey audio (*.ape files)? I like amaroK a lot but I believe I won't be able to play my *.ape files with xine (or whatever else after gstreamer dissappears).

#5 Jopanku on 2006-05-19 04:48 (Reply)

Gstreamer has already disappeared.

But yea, you might be correct. Though I'm not sure gstreamer 0.10 supports ape regardless.

#5.1 Ian Monroe (Homepage) on 2006-05-19 08:01 (Reply)

There are a couple of file formats that xine and helix don't support, e.g. sid-files.

That's why I like gstreamer, it has plugins for everything, especially for all the strange audio-formats from past computers out there. And therefore I wonder why you abadon gstreamer because the other engines are more "complete". Atm, xine and others are less complete for me.

#5.2 Hanno Boeck (Homepage) on 2006-05-20 10:23 (Reply)

Its just our interface (the engine) with gstreamer thats incomplete.

#5.2.1 Ian Monroe (Homepage) on 2006-05-20 11:24 (Reply)

I for one hope amaroK's gstreamer backend gets maintained soon again. I'm a big fan of gstreamer, and it was actually one of the reasons I, as a GNOME fan, could easily turn to amaroK. GNOME had no good music player (Rhythmbox was buggy, slow, and not very well featured), but KDE had this cutely named thing called amaroK - oh, it uses gstreamer too, no wasted disk space then, so there we came!

It's weird how I can feel so strongly about this. I'm not much of a GUI application programmer. What comes to multimedia apps, I'm an *end user*, practically. Yet, I saw gstreamer as a good idea that's worth investing in. Yet, lately, in my writings, I was exploring the theme of abandoning graceful, yet so far incomplete, approaches in favor of potentially ugly strategies that bring good results immediately. And now, here, I'm kind of running into a practical example of this motif.

"GStreamer isn't stable enough of an API right now"? That's the only worry you have? What happened to "GStreamer, being a complete solution to a lot of related problems, is a Good Idea and should thus be supported by default"?

#6 WWWWolf (Homepage) on 2006-05-22 08:16 (Reply)

Your kind of mixing up two issues. amaroK's dropping of gstreamer is just because our engine wasn't fully implemented and mostly bugfree yet. This is gstreamer's fault only insofar as their API is somewhat complicated compared to like Xine. And really gstreamer doesn't present much or any advantage over xine or helix for amaroK, so its redundant to support regardless.

The issue of Gstreamer's API not being stable enough for us as the KDE 4 backend... well really they probably would never be stable enough until gstreamer decides to sync up their release cycle with KDE. KDE 4 will probably last into the next decade. The gstreamer devs have never made a claim that 0.10/1.0 is going to last that long. This is why KDE can't be directly dependent on gstreamer.

#6.1 Ian Monroe (Homepage) on 2006-05-22 10:24 (Reply)

Isn't open source software about choices? Is it really that difficult to have gstreamer support? I really like the concept of gstreamer.

If it isn't stable, then it perhaps it can be turn off by default (during compilation). Gstreamer supports are still in CVS, right?

#6.1.1 SnEptUne on 2006-06-02 10:40 (Reply)

Well gstreamer have one big advantage over xine. The audio, first of all the volume is way to low with xine and I have to set the preamp to max, and even when I got a good volume it still isn't as good as with gstreamer. The difference is hearable, it's "muddier". I know this isn't just me because I've seen alot of people saying the same thing.

#6.1.2 Rizado on 2006-06-04 14:01 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry