Perspectives On KDE Multimedia

sombragris points out this interview on OfB, excerpting "Open for Business Associate Editor Eduardo Sánchez sits down with Scott Wheeler, creator and lead developer of JuK, and a member of the KDE Multimedia Team, to find out where the KDE multimedia department is headed in general, and concerning a replacement for aRts, more specifically."

Comments

A change

[MarkRose]

It's nice to see that KDE is moving away from aRts. While aRts was cool for allowing multiple sound sources to be played at once, it is quite a resource hog and has problems with latency. I know I am constantly stopping and starting aRts when I watch movies because the latency is too noticeable (or it drops too many frames with low-latency). I wish there were a more definite answer and a right-here, right-now solution, however.

Re:A change

[qurk]

Arts has improved immensely over the last couple of minor updates though. A year ago, aRts control panel was woeful and it was set up to hog the sound system no matter what. Now it is easy to set up alternate sound systems, actually turn artsd on and off, and the settings are such that now artsd will give up control of the sound server after a second or two. (No more being completely unable to play ut2004 with sound because artsd keep spawning evil demonic children everwhere). Also, half the time it just didn't work. Xmms has a arts plugin and it just recently started working for me. I guess I haven't noticed the latency issues too much, having in general stayed away from artsd sound due to these other issues :)

Re:A change

[MarkRose]

Indeed, it has improved a lots. I still find myself reaching for the kickarts applet far too often though -- the sound system should really work completely transparently. I actually avoid non-KDE apps simply because they often use a different method for sound control. It would be great if GStreamer because the sole standard for Linux on the desktop, simply because a standard is really needed (much like how we almost all use X).

Regarding latency, it is adjustable for aRts, however, the lower the latency, the higher the CPU usage, and the more sensitive it becomes to heavy loads and not getting its slice of CPU time in time. It was definitely a huge improvement over esound, but it is not without fault.

Re:A change

[qurk]

I guess most sound apps just point to /dev/dsp. I just ran a ls -l dsp* in /dev and got lr-xr-xr-x 1 root root 9 Nov 24 14:26 dsp -> sound/dsp lr-xr-xr-x 1 root root 9 Nov 24 14:26 dsp1 -> sound/dsp lr-xr-xr-x 1 root root 9 Nov 24 14:26 dsp2 -> sound/dsp I am crossed on the issue of artsd. It's done me wrong a few times, yet I think it's mission is good and in fact it has started working well now. Given the fact that the maintainer isn't around anymore, I'd say go for it, let's go from scratch :)

In general

[Otter]

That KDE development has always been a complete free-for-all is one of the things that made it fun, but it's also been one of its big weaknesses. Especially because there's no one to say no -- because there's no hierarchical leadership like in GNOME and no acknowledged dictator with the willingness to use his power, like Linus. That's why every possible option gets added anyplace anyone wants it and why the packages keep getting bloated with more redundant or specialized applications. (Does kdegraphics really need a POV-Ray front end?)

And kdemultimedia has always been the weakest point in the KDE lineup, partly as a result of no one to enforce policy in it. aRts and noatun became its centerpieces because each had an enthusiastic developer pushing it. JuK, on the other hand, is a very nice piece of work (next to iTunes, my favorite music player) and hopefully Scott Wheeler's influence in the vacuum that seems to have appeared will improve things.

Re:In general

[Kick the Donkey]

Maybe the question you should be asking yourself is: "Why doesn't GNOME have a POV-Ray front end?"

Re:In general

[Otter]

Unless you think that such an application could only exist in one of the base GNOME packages -- no, that question has absolutely nothing whatsoever to do with my point.

Re:In general

[Ed Avis]

Since POV-Ray is not free software there isn't that much point including a front end for it in GNOME. If you're asking 'why has nobody written a POV-Ray front end using the GNOME libraries and the GNOME look and feel' that is a slightly different question.

Re:In general

[Kick the Donkey]

No, I was more or less just being an ass. ;)

And GNOME too

[BRSloth]

Interesting, the GNOME folks are also rethinking changing the old eSound to something else.

Can I be the first one to say that "this will be the year of audio on Linux Desktop?" :)

Arts is truly remarkable system

[rzei]

Arts is a truly remarkable system, at least scalability-wise, as here it is able to produce skips and strange decoding errors no matter how modern x86 runs it!

On my old Pentium-II 333MHz 384MB a 5-10% CPU use while playing mp3's was almost a great achievement, but boy, was I surprised when I got a new system a year ago (Athlon XP 1800+, KT400 based), arts was still able to use those 5-10% CPU and producing all the same kind of errors and skips..

I love arts.

To be serious for a moment.. I'm not sure whether a Microsoft like approach to handling multimedia is right. It sounds good on paper, but would it be possible to accomplish, without overcomplicating things (again)?

Re:Arts is truly remarkable system

[Minna Kirai]

as here it is able to produce skips and strange decoding errors no matter how modern x86

Just re-confirming what you say: I have an AMD Athlon 64 at 2200 mhz, and arts audio is just as delayed and garbled as on a 500mhz P3.

However, I'm not overly impressed with their scalability, as the competing Gnome esound has achieved similar levels of performance.