aRts/KDE Video Roadmap Meeting

All aRts and KDE developers (or would-be developers) are invited to an IRC meeting in order to draft a short- and long-term roadmap for the future of video in aRts and KDE. Why? aRts is a solid base, and it would be a shame not to build a good video system on top of that, taking the best from the already existing video projects.

When: Saturday, January 26, 2002
21:00 GMT / 22:00 CET / 13:00 PST / 16:00 EST

Where: #kde-multimedia on

How:kSirc in kdenetwork
(or KVirc if you insist)

Dot Categories: 


by dmalloc (not verified)

or .. Irssi, IrcII, BitchX, Xchat etc etc etc *grin*

by Shift (not verified)

Or mIrc....

Ok I ---> []


by Neil Stevens (not verified)

Anyone using mirc will be kicked and banned. :-)

by Evan "JabberWok... (not verified)

I doubt it - I just moved, and was stuck on a Windows machine for a week (my roommate's with a modem) while I waited for DSL. Luckily nobody kicked or banned me in any *nix dev channel for using mIRC.

Maybe you're a wee bit less open?


by Erik Hensema (not verified)

Maybe you are some newbie who doesn't understand a smiley?

by Evan "JabberWok... (not verified)

Yes. Yes, I am a newbie. Excellent perceptive skills and cunning repartee, sir.


by anonymous (not verified)

People like you should be shot in the head.

by ac (not verified)

... or be forced to use mirc. :)

by cylab (not verified)

Nobody should ever be shot in the head! seriously!

by stephan (not verified)

>People like you should be shot in the head.

Don't tell me - you are that Israeli guy, aren't you? Thank god you probably don't know who the poster really is. Please don't bring such attitudes into this forum.

by domi (not verified)

BitchX rules !

I'm not sure if I am alone in this comment or not. But, my experience, KDE 2.1.1 to 2.2.2 with artsd has been very disappointing to say the least. I have a Tecra 8100 laptop 600 MHz (256M Ram) that esound and regular linux sound works great on. Plugging in artsd, though, creates the most *nasty* choppy sound on the planet. I moved around kernels between 2.2.x to 2.4.7 to 2.4.9 to 2.4.17 and still get the same results. I changed all the bitrate crap, adjusted how much CPU usage and tweaked about everything except my hair before I just gave up.

I also have an i810 600MHz with 256M Ram as well. It improves the artsd server a little bit, but I still get the occasional snap,crackle,pop.

I'd like to use noatun, but XMMS is so much better. 90% of the noatun's problem is artsd, 10% is speed.

Please improve artsd! I am an avid KDE fan and would like to be as pure as I can to help with bettering this desktop.

by Neil Stevens (not verified)

hm, as the bottom of the page here just said:

"The trick is not to dream of adding a feature, but simply to do it." -- Stefan Westerfeld

by Stuart Herring (not verified)

Have you tried using the preemptive kernel patch?

I've not had much of a problem with artsd as a general rule, and would only get the occansional choppyness when really stressing out the machine (Starting oracle and booting windows under VMWare at the same time)
But the preemptive kernel patch has removed even those problems, and I can use artsd quite happily with a response time of 40ms.

I also don't use Noatun, as I prefer XMMS's playlist, but I do use the artsd output plugin for XMMs....and I play mp3s all day without problem.

Yes I've used preemptive. The only thing I haven't done is move to ALSA. I will try that when 2.4.18 comes out.

Are you using the sound drivers in the linux kernel, or drivers from the ALSA project? In my experience, ALSA drivers are higher quality. If you aren't using ALSA, try that. That solved some problems I was having with aRts.

That worked for me too, in particular for my i815
integrated sound card on my laptop, but I got
improvements also on the AC97 one on my desktop...
ALSA is definitely better...

Yes, reading the rest of this thread I think that many people's problems are caused by the bad sound drivers included with the Linux kernel. Those drivers work OK for some things but aRts seems to just kill them. I read somewhere that aRts uses unusual features of the sound drivers that most other programs don't use, which would explain why for example esound works. Hopefully the 2.5.x kernel series in development now will make the switch to ALSA so that when 2.6.x is out Linux will finally have large numbers of high quality native sound drivers.

by Sven Geier (not verified)

In re: "Hopefully the 2.5.x kernel series in development now will make the switch to ALSA"

ALSA has been integrated to the official Linux 2.5 tree.
The initial merge is in patch-2.5.5-pre1, which included the 0.9.0beta9 packages

I used Noatun a while when 2.0 was new, but it was quite sueless for me. Any normal desktop activity caused it to skip, and it crashed too often. I tried packages of KDE (Mandrake at the time), manually compiled, and CVS releases. Now I use the Debian Woody packages, and it still isn't stable, so I'm back to xmms land. :( If I was technical enough I could submit bug reports, but nobody wants to see "I played some music and it died" in a report.

I also don't know why it should take so long to load, i.e. several times longer than xmms, and use so much memory.

I think Noatun/arts will be good when it works, and I'll keep trying it regularly, but for now I've removed it from all file associations etc.

Try to increase the size of the audio buffer (in KControl/SoundServer/SoundIO).

Oh, that has been done. Without it I couldn't even move a window without skipping. :) There were some other settings I fiddled with too, and some helped a bit.

by Rumcajs (not verified)

For me It also skips when I move window ( having gcc, knode and a few konquerors running on my K6/400 128MB, especially at linking stage ). Hey people, stop complaining ! Artsd/noatrun is quite good - I find xmms worse ( I didn't try to change default settings ).

"manually compiled, and CVS releases" ... "If I was technical enough I could submit bug reports"

If you can checkout stuf from CVS, build and install it, I think you are more than capable of a useful bug report!

Noatun was introduced in KDE 2.1.

I've tried all versions of Noatun till kde 2.2.2, but the sound is extremely choppy, and continued heavy use of resources.
Using xmms with artsd plugin makes xmms also produce choppy sound. The only way seems to be toi disable arts from autostarting, and then using xmms directly with oss drivers, for decent sound.
I think as an end user, i would prefer if noatun would first play audio files atleast as well as xmms, and then we should look at video playback.

I completelly agree! I found esd (e sound daemon) much faster than artsd with xmms, but unfortunatelly i use mandrake 8.1 and have problems to get esd running (sometimes - it depends on weather? - i get luck to start esd, but i don't know how...). it always tells me:
esd: Failed to fix mode of /tmp/.esd to 1777.
Try -trust to force esd to start.
esd: Esound sound daemon unable to create unix domain socket:
The socket is not accessible by esd.
...even if i tryied everything possible to do with the =socket file in /tmp/.esd.
i never had such problems with esd under redhat 7.1 but i'm too lazy to switch back, so i have to use that slow artsd when i want to hear few simultaneous sounds in my KDE 2.2.1 (i have got a poor amdk6/233, 128mb ram). arts works, but is really slow for me...

by Ill Logik (not verified)


chown -cR .audio /tmp/.esd/

thnx! it helped with esd -d /dev/sound/dsp command. but i have another problem... is it possible to run esd (artsd) available for more than just one user?


If you want ESD available globally, try this (I got it straight from the freshmeat page)

1. In your startup file (I use /etc/rc.d/rc.local -> Peanut Linux; yours may vary) add:
/usr/local/bin/esd &
sleep 1
/usr/local/bin/esdctl unlock

2. In /etc/profile, add:
export LD_PRELOAD="/usr/local/ /usr/local/lib/"

Make sure the paths are correct...this is for my Peanut Linux setup (Slackware-derivative) using Esd 0.2.29 with default install path.

Run /etc/rc.d/rc.M (or your equivalent) to restart the default runlevel and login again. If you hear the beeps and get no errors when starting X, everything should be OK.

by standsolid (not verified)

is there any way to start artsd in esd, like how i would start esd as
$ artsdsp esd

can i edit some kde startscript to make arts flow to esd?

"do it yourself"

uhm, if arts wants more developers it needs decent docs. last time i checked
it wasn't so.

by richard june (not verified)

What about network audio? I've never gotten that to work, else I would use arts. I would much prefer to actually get sound in KDE *and* be able to stream audio from another system...

by Stephan (not verified)

My experience with arts on my machine at home(SuSE 7.3, K6-200, 96MB) hasn't been very good. While it works as expected it uses way too much CPU. Running xmms and playing an mp3 uses half of the CPU. Killing artsd and using just OSS for playback needs only 3% CPU.

Because of this it's not possible to use noatun for MPEG-Movies with sound because there is almost no CPU-power left for the movie itself. Everything is needed by artsd. So I just disabled artsd and use xmms and xine for audio/video and the performance problem has gone away.

I wonder if anybody knows where this overhead comes from...and if there is a solution?!

by Tim Jansen (not verified)

Without knowing Arts' performance characteristics I would blame it on the IPC/MCOP stuff and/or conversion on the server side. As xmms is not a native arts app it must send all the sound data to arts, arts will (maybe) convert it to whatever format the sournd card requires and only then they you hear that.

With a native arts app this can be done differently, you can do everything inside arts and only pass control commands (open file/start/stop/forward) from the app to arts. Then there should be no noticable difference in performance between a traditional app and an arts-based. For video the app would probably give a window id to arts and arts would put the video in the window for the app.


by Stephan (not verified)

As XMMS has an arts output plugin I consider it to be a native aRts app. Also the performance is about the same for the combination Noatun/artsd and XMMS/artsd. I would like to try Noatun with direct output to OSS or ALSA but AFAIK this is not possible(?!).

by Tim Jansen (not verified)

The arts output plugin doesn't make any difference since the decoding is still done in XMMS's process, not in artsd.

by Sean Russell (not verified)

This doesn't make any difference. artsd sucks up the CPU using the KDE media player noatun. And while noatun works on my laptop, it hangs on my desktop (with a gen-u-wine SB Awe 32 audio card... can you get more standard than that?). This, with KDE 2.2.2.

Every once in a while I try artsd, but usually I have it disabled it and just use XMMS. I'd be more willing to mess with it if it wasn't such a CPU hog.

I thoought I was the only one having problems with arts...
It takes all my CPU (I have 1Ghz clock speed). I also use XMMS because it works better and consumes less CPU in my case.

The strange thing is that it must work on the arts developers computers... Maybe they did some configuration changes and forgot telling to other people?

I've installed KDE 2.2.2 on several computers with several sound cards (always using OSS), and I've never had any problem using artsd....
And I'm not a developer :-)

just use bash: top

by Aaron J. Seigo (not verified)

i too used to feel that aRts was the most beta-ish software in KDE during the KDE2 run. aRts would routinely crash and it wasn't very efficient. in short, it sucked on my system here (which got me into an argument or two with Neil and Charles on IRC ;). it did get better but never got Great.

then KDE3 devel started and the first thing i noticed when i jumped back to CVS HEAD when things settled down a bit was that aRts didn't crash anymore. and it was noticeably more efficient.

i'm not sure if it was the move to the GSL code or if my luck has simply changed, but i'm quite happy with aRts now. it doesn't feel / behave like it is a beta release anymore =)

That's great news!

aRts really has been one of the weaker parts of KDE, which is a shame since it has so much potential. The problems with sound skips and CPU usage have really held it down. Hopefully in KDE3 aRts will mature into the multimedia framework to end all multimedia frameworks!

Same goes for me. But with the TOSS driver in kde3 it doesn't take more cpu than xmms for ogg even with freereverb or mplayer for mpeg. ~0.1% cpu for both. No CPU usage what so ever when it's idle i had to dissable the autosuspend to avoid crashes but how needs it now :)

by Phil Ozen (not verified)

As a user, I always try to look what's available outside KDE.

Today, in the Linux VIDEO arena, we have very good projects around. There's another multimedia framework "Gstreamer" and 2 video players that support most formats: "mplayer" & "Xine" (other projects like "Ogle DVD player" & "VideoLan" & "AVI file" support limited formats).

How KDE can take advantage from these available multimedia ressources ?

For good video support in KDE, we need:
1) aRts framework to be able to stream video
2) a good video player
3) a set of libraries to decode (and encode ?) video streams.

For item 1, aRts will be a much better video framework due to its new core (made in collaboration with Tim Janik of BEAST project:

For item 2, two choices are possible:

Choice a) To continue to use Noatun and improve its video support. Today, mplayer and Xine are the best but Mplayer got many developpers and is growing very fast. It can be a good model for Noatun to evoluate as a good Video player.

Choice b) To use Noatun for audio & use another (or others) player for video. Today, it's what happened with aKtion. We can do the same and convert Mplayer or Xine into PlayObject. This solution is fast but aRts is only used for the sound & video output. The meaning of aRts as a framework is useless then.

For item 3, two choices are possible:

Choice a) To continue with "mpeglib" from Martin Vogt. I think it's THE weakness of aRts since it's done by one man only and is monolithic.

Choice b) To accept libraries from other projects through plugins. This is the method used by Gstreamer: they re-use existing libraries by interfacing them to Gstreamer network. They don't create libraries themselves and focus on the framework instead.

Both aRts ( & Gstreamer ( are very similar: a framework on which you can plug modules & a graphical tool is available to do it. ARts can benefit from Gstreamer by re-using its plugins (which are a lot). However, I don't know how difficult it is (maybe a common plugin API between Gstreamer & aRts ?)

I hope these ideas can help. Thanks KDE multimedia developpers.

by Nick Betcher (not verified)

Hello people! Noatun doesn't decode your hax0r 31337 MP3s. aRts does. Noatun doesn't play movies, aRts does. Noatun doesn't decode. Noatun doesn't have codecs. Noatun doesn't take your CPU. Noatun doesn't skip, and last but not least, Noatun doesn't play ANYTHING! aRts does! If you want to play a Quicktime video in Noatun, you just tell aRts how to do it, recompile it, re-load it. Noatun will play it then because all Noatun does is talks to the server (aRts).

_ARTSD_ uses mpeglib. This isn't about Noatun, this is about aRts. Read the post: "aRts/KDE Video Roadmap Meeting" NOT "aRts/Noatun".

--Nick Betcher

by Tim Jansen (not verified)

2a) Pure players like Xine, mplayers and all the others won't get you anywhere. Well, almost, you can use them for playback of files which may be the most important use case, but not more. They usually have *very* inflexible plugin mechanisms, optimized for playback of files. Among other things, they usually lack (without wanting to criticize a specific player):

- the support of encoding (think of video conferencing, video mails, video editing, tv recording)
- the support for decoding without realtime (video editing, re-encoding)
- the support for push mechanisms (when you have data in a file or get it from a TCP connection pulling is ok; if a codec is embedded in a multiplexer or gets data from UDP/RTP/Multicasts/whatever the situation is very different)
- the support for filters

These players are ok as an interim solution, but in the end they will be wasted effort. The good thing is that, partially because of their popularity, many people have written codecs that can easily be rewritten for a better framework.

3b) GStreamer is fine, but uses this ugly GObject framework that makes it hardly usable for most sane people :)


> they usually lack (without wanting to criticize a specific player):
> - the support of encoding (think of video conferencing, video mails, video editing, tv recording)
> - the support for decoding without realtime (video editing, re-encoding)
> - the support for push mechanisms (when you have data in a file or get it from a TCP connection pulling is ok; if a codec is embedded in a multiplexer or gets data from UDP/RTP/Multicasts/whatever the situation is very different)
> - the support for filters

mplayer's got ALL of those features...

by Evan "JabberWok... (not verified)

:: mplayer's got ALL of those features...

Both MPlayer and VideoLAN. Both of which are GUI independant projects that use plugins for the entire front end. Both of which, like aRts, are designed to work with any WM or Environment, and have a good solid base of plugins to read everything from DVDs to DivX ;-) files.


by Tim Jansen (not verified)

Actually mplayer does not even have a real plugin-structure, it is a huge cut&pasted hack that's illegal to distribute in binary form because of its mix of licenses. It's very good at what it does, but almost everything is hardcoded. Decoding is done in a huge switch statement, you cannot just edit a filter without editing the mplayer core and recompile it. It's completely unusable for implementing, say, a new video editing or conferencing tool.