Scott Wheeler: Perspectives on KDE Multimedia

Open for Business associate editor Eduardo Sánchez interviewed 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.

Dot Categories: 

Comments

by Fast_Rizwaan (not verified)

of course with win32 codecs installed from mplayer's site.

by Nick Boughton (not verified)

I beg to differ, noatun is klunky and under performs compared to almost every other media player I've used and considering it's been around for about as long as mplayer and xine I can't see why it shouldn't learn something from them. They both load incredibly fast and are excellent at playing almost all media types. I'm sticking with kmplayer and just waiting it to develop a little more functionality, failing that there's always xine.

by ac (not verified)

OSS could only be opened by one process IIRC, but alsa does not have this
limitation.

So why can't kde apps just use alsa directly?

Only problem I see would be missing network transparency, and this could easy
be done by a kde deamon that would redirect sound from remote clients to alsa
again...
KDE apps running locally would/should only talk to alsa directly.

btw arts sucks as playing mp3 with juk on my p3-450 uses about 20% cpu constantly... :-(

by smt (not verified)

- OSS doesn't have the limitation of being used by only one program, some hardware does-- e.g, using OSS and a SBLive, you can use it more than once without any sound server
- ALSA (and OSS) are Linux specific, so they can't be used directly without other choices. That's why the plugin frameworks of gstreamer and NMM help.

by Morty (not verified)

The soundserver is there to allow to programs to play sounds simultaneously on soundcards who don't support this. Neither GStreamer or NMM can help with this as they are on a higher level, they need a output pluggin connecting to some kind of "soundserver" either a soundcard running alsa/oss/whatever who can handle multiple streams or some kind of sw soundserver like aRts/esd/whatever. In lots cases you still ends up with the need of a soundserver as most PC don't have the hardware.

by Mark Kretschmann (not verified)

Again, Alsa and other modern audio frameworks provide software mixing when no hardware support is available. For Alsa this is handled by the "dmix" plugin. These built-in mixing facilities make sound servers unnecessary in most cases (see discussion above).

Here's a link providing some information on dmix:
http://opensrc.org/alsa/index.php?page=DmixPlugin

by Navindra Umanee (not verified)

I still think this dmix stuff is ridiculous and over-engineered. Really, this stuff should be handled transparently behind /dev/dsp and the usual sound devices instead of requiring user-intervention through the use of asoundrc and wrappers.

by Mark Kretschmann (not verified)

The whole point of dmix is transparency. All the user needs to do is use the dmix device instead of e.g. hw:1. No more intervention is needed, and certainly no "wrappers" are required.

In fact, a sound server rather fits the definition of a wrapper.

by Navindra Umanee (not verified)

And what's aoss for? That's a wrapper as far as I know i.e. dmix requires wrappers to /really/ work, yet everyone happily claims that it somehow doesn't.

I'm *no* fan of soundservers. What's I'm saying is that alsa should do its blackmagic behind /dev/dsp and not concern users with arcane stuff like dmix, aoss, hw:1 and so on.

by Bausi (not verified)

aoss preloads a library that emulates an oss device. So you can use older/propietary apps which don't have native alsa support. The app thinks it talks to oss, but in fact it talks to alsa. realplayer is a prominent example where this is useful.

by Navindra Umanee (not verified)

I know that. My point is that you need it. There are many such prominent examples and less prominent examples (such as practically every other portable Unix sound app in existence).

If everything used ALSA it could have been fine. But like aRts, that hasn't happened and is not the reality of the situation.

by Martin (not verified)

That surely means that alsa and the dmix plugin is still the best solution though however. At least in some circumstances, and its an increasing number, no "wrapper" is required.. if you're suggesting a soundserver is a better solution i think in every circumstance a "wrapper" would be required. What i believe was suggested was to encourage all programs to use alsa directly and eliminate this problem completly... you're correct in pointing out all programs don't do this all ready otherwise that suggestion wouldn't have been made!

Martin

by Navindra Umanee (not verified)

It's not the best solution. The best solution is to support multiple access to the sound device transparently. How to put this. The best solution is the solution where the user does not have to concern himself *at all* with ALSA technical details.

If you meant that it's the best solution available now, I have no idea. It certainly doesn't work for me. It probably requires me to read tons and tons of manuals and to compile new kernels to get it to work. ALSA has been around for ages, and still for all practical purposes my /dev/dsp only lets one application access it...

I don't understand your point about aRts vs ALSA. aRts does the same work that dmix does on that end. If you use the aRts API, the output gets mixed with other applications that use the aRts API. It's the same thing with dmix, no? Only difference is that you use the ALSA API instead of the aRts API and dmix takes care of the mixing.

aoss is then similar to artsdsp.

And btw, what about portable Unix sound? Encouraging all apps to use ALSA directly is as realistic as encourage all apps to use aRts directly. Most commercial applications will be forced to support both OSS and ALSA.

by Mr. Fancypants (not verified)

QUOTE: "It's the same thing with dmix, no? Only difference is that you use the ALSA API instead of the aRts API and dmix takes care of the mixing."

Sorry to barge in, but dmix has much more limited mixing capabilities than arts. For one, it requires that all applications outputting to dmix use the exact same sample rate. This means that any application outputting audio must, in principle, have the ability to resample its audio on-the-fly. Arts does that automatically, so app-writing becomes easier (ie. you don't have to implement it yourself).

This related to the larger point that "direct" ALSA is *NOT* an viable alternative to arts/gst/nmm. The main reason is that they are simply operating at different levels of abstraction: arts/gst/nmm take care of downsampling, mixing, multistream sync, file formats, etc. etc. whereas alsa basically ONLY takes care of mixing. Essentially, replacing arts with ALSA would mean that all applications would have to go back to implementing their own mp3/ogg decoders, their own latency-compensation, etc. In other words: Not a good idea.

by Angry Linux User (not verified)

>In other words: Not a good idea.

I think the point was:
>The best solution is to support multiple access to the sound device transparently.

As such, the 'difference' between arts and dmix is simply a matter of features. If mixing were handled with 'arts features', but in the underlying ALSA device drivers (assuming it were possible), then ALL problems with device access conflicts would be simultaneously eliminated, and arts/esd/etc. would still run with no problems (for legacy purposes) since they each "think" that they're directly accessing the sound device. Similarly, the OSS emulation modules would be mixed into the data stream automagically, since mixing is done at the device level.

I assume something of this sort is possible, since Windows seems to do just fine. Unless, of course, it's a matter of Windows just using one standard soundserver whereas Linux has many that don't coexist nicely - an excellent argument against OpenSource, incidentally, even though I love the idea and the customizability (except for ALSA).

In fact, ALSA is a major motivation for me to use Windows right now. Dmix fails whenever CPU load goes above 70% (causing all related sound applications to either freeze or go into 'silent fast-forward' mode), and I can't even get arts to run through ALSA/dmix - and if I run it through ESD, which DOES work with dmix, initializing arts brings CPU load to 100% momentarily, killing dmix and causing ESD to hang. This is probably related to the fact that I get skipping problems at the same CPU load when using ALSA devices directly without going through the dmix plugin.

By comparison, on the same hardware, Windows just keeps on pluggin' on no matter what I do, no matter the CPU load, and sometimes even keeps on going after the rest of the system has crashed. I assume MacOS works as well as Windows does, if not better. So why isn't Linux up there competing with the rest of the gang?

by Stuart Gathman (not verified)

Many of us use LTSP to allow multiple users. Workstation sound works by running esd on the workstation. Esd adds lots of latency, but works fine for desktop noises and audio players. You can even watch movies on a workstation if the video card support XV (but it saturates a 100baseT LAN).

Via LTSP, our family runs 4 workstations (built from junked 400-800Mhz celerons and 17" CRTs) on a single $400 server (Dell 500SC). The only problem is explaining to the kids why they can't download and run all the Windows only binaries offered on the net.

I would like to see esd feed into jack on the console. Then jack would handle realtime stuff, and esd would handle all the noises and audio players.

by superstoned (not verified)

you might check if you have the right software installed, I dont remember exactly, but google will be able to tell you about it: arts CAN use external software for playing music, which will decrease its processoruse with some huge factor...

by Tomislav (not verified)

I think that major obstacle for multimedia (and desktop generally) is not a lack of good apps, nor the kernel itself. On user side end, KDE is really fulfeatured, and eye-candy. On the low-level side, kernel is rock solid. What we miss is "midle tier". Actually, we don't miss it, but it is somewhat problematic.

For instance, big problem used to be font rendering. It is solved now (now only patent issues prevent you from using hints in TT fonts), but all of you remember those "fonts look ugly" topics.

On other fields: For instance, you may change mouse acceleration easily in KDE, but you cannot change a mouse resolution. It is not some KDE problem - problem is (correct me if I am wrong) that there is xset option that sets acceleration, but there is no xset option to set resolution. Also, I was very confused why I cannot set alt-shift to act like ctrl-shift-K in KDE (it does not work in RH 7.{0,1,2,3}, RH8, RH9, Suse9.{1,2}). Finally, I found that not to be KDE related problem, but related to X system. I hope that many problems related to X will be solved now when we have X.org instead of that laggy XFree team.

Also, arts deamon is a thing that we will not miss once it goes away. Ok, this is actually a kernel issue; but mixing server sounded like a bad idea from the scratch, no matter that no other workaround existed.

One thing that I will not miss if it goes away is cdrecord. (K3b and other stuff are just shells around it.) Cdrecord is beast for itself. I used to have page in my (paper) notebook where it was written how to use it. I am BsC in EE, and I use CLI 15 years now, but still, I was not able to remember cdrecords bizzare parameters. And it had some wierd behavior with Matsushita drive, spitting a message when noone (i.e. no shell) expected, forcing me to use it from the command line. Not something you would do for fun, believe me.

And there are many things like this. Fortunately, all these mentioed stuff are progressing in good direction now. Thing that worries me is why it cannot be faster? Or maybe I just compare everything to the speed of KDE develoment;)

Juct my .02$

Tomislav

by charles samuels (not verified)

Just so you know, Noatun is still being actively developed and we plan on numerous improvements (probably for KDE4) to how Noatun behaves. This is evidenced by the new development branch that was just created.

1) To those who are complaining about crashes in Noatun, there was a release of what I call the "Magic Crashing Version" -- basically, something changed in Qt that we didn't find until it was too late, then didn't know how to fix (eh.. workaround) for ages (this was some interaction with KDialogBase, and resulted in quite a lot of complaining from me!). That was the only crash I was aware of.

2) About skipping in the playback. That is now quite thankfully resolved, as of the 3.3 release, KDE has switched aKode which handles it much better. It also helps to use a Linux 2.6 kernel, as 2.4 has incredibly awful disk IO.

3) Noatun is not optimised as a video player. Video is supported quite nicely, and I personally am able to play pretty much every format I can throw at it. You need to have xinelib installed at the time. But calling it a "Media Player" I've decided is rather innacurate, because I use it just as something to give myself music over the course of the day. And I should mention that I use it a lot.

4) Yes, I can play shoutcast, and as of KDE 3.4 (or maybe it's 3.3, I don't remember :) - it will/does also get the icecast song title.

5) If you're unhappy with the playlist, please consider using my latest experiment in playlistitude, Oblique, in kdeaddons. There's also FlexPlaylist which is a bit more customisable.

6) If you can crash it, and you don't use Gentoo with all sorts of insane optimisations, and you actually installed arts correctly (it, sadly, needs to be installed in the same prefix as noatun), then I will assume you're a lying troll unless you report a bug. I honestly do not know how to crash noatun as of KDE 3.3.0. In fact, I don't even know how to crash the HEAD cvs branch.

7) Remember, nobody is forcing you to use it. When I, and any other Noatun developer writes it, we write what we want to use ourselves. If you are not happy with what we write, then you are free to either make a suggestion to improve it, send a patch, or just use another program.

8) Just because you don't like it doesn't mean other people don't.

9) I play mp3, ogg, mpc, flac, and DivX files quite regularly without problems, if you can't maybe something wasn't installed?

Again, yes, Noatun is a "different" sort of program. It's different from the ground up by design, we like what we have, and since we are our favourite users, we will do what we want!

by Darkelve (not verified)

I loved it, also because it resembles the old WinAmp a lot, it looked pretty good and was very usable. And it was very customizable too. Only to add songs to playlist was a bit awkward, but I am talking about the Noatun version included with Mepis (the Mepis version before it became SimplyMepis). I use amaroK now, it was provided by SuSe and it is very good too, but I would like to try Noatun sometime again nevertheless. Noatun has a product page somewhere?

by charles samuels (not verified)

noatun.kde.org -- it's hardly updated, however, because we rather be coding C++ than playing with HTML :)

-Charles

by ac (not verified)

>>Again, yes, Noatun is a "different" sort of program. It's different from the ground up by design, we like what we have, and since we are our favourite users, we will do what we want!

No hard feelings, but, do what you want for yourselves then, but do not shove it down default KDE installed base it's throat.

Do you accept many, many people want to see Noatun OUT? Do you accept that, or are you stubbornly going to stick with the: "WE are our favorite users" and "that's what KDE users will have to accept", nevermind other, much, much more practical and prooven projects being embraced in a 'mass' sigh of relieve?

by superstoned (not verified)

nah, if noatun is better now as it was the last time I tried (must have been the I-love-to-crash-version) why not let it stay? maybe give it plugins for an juk-like playlist, and some amarok-features, and juk/amarok might even become obsolete :D

I'm goin' to install & try noatun now...

by superstoned (not verified)

and I didnt like it at all. not easy-to-use playlists (kde 3.3.1), no easy all-in-one skin (a skin that shows playlist and controls in 1 window), no quick searching (like juk and amarok have), no playlist handling (eg you have to click thourgh several windows to load another playlist, instead of just selecting it in juk, or rightclick->load in amarok.

no, its nice compared to xmms, but xmms sucks compared to juk and amarok. once you got used to their nice interfaces, no way of going back...

by charles samuels (not verified)

try Oblique, in kdeaddons.

The only thing it doesn't have is an "all in one" UI. That's something that will be addressed in the future.

by charles samuels (not verified)

I think you missed my points #7 (Nobody is forcing you to use it) and #8 (just because you don't like it doesn't mean everyone doesn't)

by Oliveira (not verified)

I am very happy with all the discussion about multimedia, but I have
a simple question that I never could answer: what is the status of
video playing in KDE (or Linux in general) for embedded video with
M$ mediaplayer plugins? I don't know how to setup this (if it is really
possible) and look that I like to setup software by hand! KDE should
try to fill this gap, because there is a huge amount of people who like
to see media in embedded players -- this is the reason why my wife
doesn't use linux (at least the excuse she uses!!) It would be good
to have at least manuals explaining how to do this for the multimedia-non-
initiated. The best would be to have mplayer/xine integrated to play
embedded MS video in KDE out of the box.

by superstoned (not verified)

kaffeine AND kmplayer can do this both, embedded in firefox AND konqueror. what are you complaining about?

using an old version of these apps? or you dont have these plugins installed? what distribution are you using? it should work out-of-the box on a recent and userfriendly distribution...

what distribution are you using? it should work out-of-the box on a recent and userfriendly distribution

Clearly it is not in this case. Surely, this is not the only case.

However way you put it, multimedia and just working out the box is something which is going to take some time and solving of many (legal) issues.

by superstoned (not verified)

well, never had much troubles with mepis linux.

by superstoned (not verified)

neither with mandrake, by the way. and stock-debian just required the installation of some packages. knoppix does it, fine, if I recall rightly. so, what distribution does it this bad? red hat I guess? alwasy sucked at multimedia... just dont use it...

by Jonas (not verified)

Gentoo works perfectly. I just 'emerge kaffeine' and voilà, also after emerging some codecs with dubious legal status the Apple movie trailers in Quicktime play directly in my Konqueror browser.

by Nilesh Bansal (not verified)

One of practical problems with arts is that it runs as a process (which blocks all other programs trying to access soundcard directly). This is because, only one process can access soundcard at a time (I don't know why most distros do not configure software mixing in alsa by default?). Problem arises when I want to use application with bad arts support (like with mplayer volume keys don't work).

All soundservers suffer from this problem and IMO its best to use alsa (with software mixing. dmix?).

by Virgil Nisly (not verified)

Where can I get graphics equalizer for amarok (with gstreamer backend)? I can't find much around about it-freedesktop.org went down and is back... but it lost some content, and amarok.kde.org isn't back yet :(.

Cheers!
Virgil

by Mark Kretschmann (not verified)

amaroK CVS HEAD features a 10-band graphic equalizer for xine and GStreamer. Check out CVS, or wait for 1.2-beta1 (soon).

by Virgil Nisly (not verified)

Thanks!
I saw that, but it didn't make any sense to me until you said something about it. Checking out cvs now:)
Virgil