Comments

Although there recently has been a mood that Arts should be dumped, I think we still owe Stefan a big Thank you! Arts has powered the multimedia in KDE for many years, and though it has it's problems, it isn't that bad at all. Sure, it may get replaced by something more modern and fit to the broad desktop-usage that is envisioned for KDE, but in the meantime, it has served us well. Thank you Stefan!

besides the current arts ranting... it's still able to provide stuff no other piece of software in this area achieved, yet. but as stefan explained, it's a sound-serving-decoding-coffee-cooking-doing-everything solution, which is hard to maintain. thanks for all your effort!

What applications are at the frontline to replace aRTs in KDE. Where can one get info? What does that mean for future KDE multimedia development? I heard the the "analyzer lag" in amaroK was due to aRTS. What are aRTS's other problems?

but to give a short answer:
-info: search the dot and google
-future: well, another solution has to be found...
-yep, arts isnt that fast, so the lag was due to arts.
-read the doc and the comments on the web. mostly: high latency, hi processor use, hard to work on.
-so KDE (and the whole FSworld) is looking for a replacement. NNM (or was it NMM?), MAS and Gstreamer seem to be in the picture. amarok and juk already support gstreamer, amarok also supports both other soundservers.

There's always going to be an inherent latency when you're pumping audio from software to the sound card's dma buffers on a non-realtime multitasking operating system. The way to solve that problem is to add a delay between the decoder and the visualisation that's equal to that of the decoder and the speakers. aRts cannot be held to blame if the application doesn't do that.

The latency is completely configurable between "as little as possible" to "as much as reasonably possible" And certainly less than XMMS does. I've seen players that take a bit to respond after a pause or seek, arts doesn't do this to any noticeable amount.

"It skips" so often because mpeglib (our default mp3 decoder in KDE <=3.2) didn't buffer disk accesses very well and couldn't read the mp3 data quickly enough from the disk, decoding it or sending it to the sound card wasn't the problem, but Linux 2.4's disk IO is incredibly bad (it's far worse than even I think it is!). It's much much much better in Linux 2.6.

We solved this problem by getting a new decoding plugin "aKode" (which does Vorbis, MP3, and also musepack), and buffers disk access much more. Furthermore, it does some magic calls to the kernel that say "I'm going to read in order, so buffer all you can, and unbuffer it as soon as I read it." These things pretty much have eliminated the problem entirely.

well, I haven't had any problems lately, exept for amarok, which seems to keep arts output open, blocking most other applications. but thats my main problem, now. the high cpu use and skipping have been fixed, mostly. the only problem I have with arts is that some apps can't use it natively so I have to use artsdsp (but alas, it works that way).

The problem is, that aRts' scope function always reads from the start of the sound buffer. So, if have a big buffer configured because you want to prevent skips (see kcontrol/Sound & Multimedia/Sound System/Skip prevention/Sound Buffer) then you get for several frames the same scope data delivered again and again. aRts isn't slow at that. It serves the same old and stale scope data quickly. It just *seems* as if it were slow. If you make the sound buffer as small as possible, then you'll see that there's no noticeable lag any more. One could probably have worked around that, but the sparse documentation didn't offer an apparent solution.

I have been developing a DJ application for a few years, and have found the biggest problems to be in using driver abstractions - alsa, jack, oss, and arts. aRts has always been a reliable test bed that I can fall back on when the others don't work. After a year of using the native alsa API, I'v fallen back on arts again to get my app working. Latency is a problem with arts, but My application code needs to be profiled right now, not the driver code!

... is split into two seperate components - a library for KDE that handles all the multimedia stuff, and a sound server, and that the library *can* or *can not* use the sound server based on the user's choice.

I mean, I fully understand why a sound server is needed for people without hardware mixing, but for all of us who do, having to run a sound server to provide mixing capabilities inferior to those of our card is nonsense.

The problem I have with dmix is that it does not work very well. It can only do two channels. It makes my audio sound bad (from what I have read this is to do with my sound drivers). It seems to randomly crash. It is hard to setup (anything more than just works is hard). It seems to have compatibility issues with apps.

The most worrying thing about dmix is how slow its development seems to be going. It was introduced in alsa 0.9.0 on 2003-03-02. It has only recently got to the usable state in alsa 1.0.6. And even now it has so many problems. This to me says that it A) is really hard to develop and debug, or B) it is not well maintained. Neither are good things.

Some of these new sound servers like polyaudio work great today. It does provide other neat features like network transparency, playing music across multiple devices, and plugins. But the main thing is that it works.

To me the best would be to use something like gstreamer throughout kde. That way the default audio sink and kde does not have to bind itself to any one solution. The people with good soundcards can use an alsa sink, the terminal people can use a network transparent sound server, and the people who don't use linux can use whatever they need to for mixing.

ahh yeah, and it will decode mp3, ogg, flac etc. and of course it will give me an equalizer, various ways to pipe my sound-output to somewhere else and all this with an easy to use API.
Uhm... wait, no, that's arts, not dmix.

I just have to say I think everyone that is demeaning aRts is insane... I have used aRts continuously for years and i would say at most i have one minor problem every several months. Take that in comparison with the rate at which stupid comments surface here and I'd happily take my chances with aRts.

In addition, it's frustrating to see people parrot back the *exact same problems* he has already mentioned in such a disparaging way. Perhaps it isn't all-things-to-all-people, but it is free software.

In any event many thanks! I will continue to enjoy the use of aRts while I look forward to a very bright F&OS future.