Version: 1.1.2 (using KDE KDE 3.1.2) Installed from: Debian testing/unstable Packages OS: Linux When playing mp3 or ogg files from Kaboodle or Noatun, artsd is swallowing an inacceptable amount of CPU time. The amount used depends on the encoding quality. For high-quality OGGs (encoded with -q 8), "record" load was about 60% and sound skipped every time I tried to do anything beyond moving the mouse. XMMS plays the same files without a problem with an *overall* system load of just about 3%. Even playing 1Mbit Xvid movies with xine and arts sound output doesn't cause as much load.
I've seen multiple accounts of this when playing ogg and MP3-files without the mpeglib_artsplugin. Installing mpeglib and mpeglib_artsplugin solves it. I wont close the bug, as the real isssue is that the builtin GSL-player for ogg and mp3 really really suck.
well, I vote for this - this really should be fixed. such bad performance is untolerable... whole KDE (3.2) is behaving very good, very fast - but aRts sucks...
yeah, the same situation for me. XMMS uses 5% of CPU while playing the same mp3/ogg file, but arts eats up to 60%. The system becomes unresponsive and it's hardly possible to do anything else. It's really a showsopper, should be fixed before KDE 3.2 is released, otherwise KDE Sound System would be unusable for everyting else than plain wav files on slower CPUs (well, mine is 300mhz PII).
Arts CPU use really is awful. I experience these same problems on ogg and MP3 playback under RedHat 9 (Athlon 900MHz) or Fedora 1 (P4M 2.2GHz) although I have yet to try the plugin, which I will check out tonight. Even worse, when Konsole wants to beep under Fedora 1, something about arts goes nuts and uses 100% of system CPU for over a minute. Killing artsd solves this problem, but eliminates sound entirely.
yow, how can Juk an Noatun and the other media/sound players for KDE ever get accepted if they skip, use enormous amount of CPU time, or lock the system?!?!?
Because it not a problem if you install kdemultimedia. This problem occurs in the cases I've examined, only with the build-in GSL-codec in aRts, once you install mpeglib_artsplugin they go away. Mpeglib is in kdemultimedia together with juk and noatun, and is used for playing Ogg and MP3 files.
Thanks you. With mpeglib_artsplugin installed, aRTSd now uses only about %7 of CPU while playing mp3s. IMHO, there should be a warning somewhere in "KControl->Sound Server", which would suggest installing this plugin. Otherwise, aRTSd could cause disappointment for KDE users...
so this bug can be closed..?
aRTSd native soundplaying capabilities are still very very bad... so I think this should be open until that has been fixed... but its you guys who should decide ;-) and including an warning in the soundsystem whould be the least that should be done before closing this bug, imho.
Something else I've noticed with ALSA and ARTS: CPU would go ballistic when I configured the Sound Server to 'autodetect', but once I selected ALSA, CPU came down...
well, ARTS works fine for me now - kde 3.2, kernel 2.6.2 (I think alsa 1.1.1 and/or the 2.6.0/1 kernel really had to do with the problems, but I cant really find out what). and I run mandrake - cooker (almost daily KDE CVS snapshots, kernel release candidates, etc etc, very cool, but unstable)
I run KDE 3.2 on gentoo with kernel 2.6.3 and alsa (and oss compat enabled). If I use autodetect or select Open Sound System artsd uses 100% CPU and gets choppy if I move anything but the mouse. When manually selecting alsa everything is ok, about 5% cpu load for the artsd.
This is a new one for me, too. Gentoo, KDE 3.2, and just /running/ arts makes it consume 80-90% of the CPU. That's not even playing anything through it.
This has nothing to do with the original bugreport. All the aRts+alsa(+gentoo) people use your own bugreport (which would be a duplicate of the lot others which are fixed) or tell your artsd to use alsa directly and not autodetect which defaults to oss (until kde3.2.1)... Arnold
i'm having no problems with artsd I have artswrapper suid root I have a VERY low amount of buffer, and I can play quake3 just fine with artsdsp -m quake3 maybe those of us on gentoo should review our cflags? (and the artwrappersuid useflag)
In light of recent comments. Let me summerize this bug _again_: aRts when used correctly do not have serious performance issues, BUT playing waw, ogg or mp3 without additional plugins IS a problem, as the built-in playback for these format just plain suck. There are other unrelated typical performance problems with aRts: 1. not setting it suid (a big problem if your distro renices xfree like Debian does). 2. using the OSS driver if you have ALSA These should not be reported here!
That summary is wrong, mpeglib has no performance problems.
I guess this bug could be "half-closed". It's more that the mpeglib plugin should be built into arts instead of the default playback routines. The sound skipping when doing anything (moving windows around, changing desktops, ...) is still there, but I'm thinking it's more of an issue with the applications not feeding the sound daemon properly during those events. My artswrapper is SUID root, BTW... If that is the case and can be confirmend by a qualified source, let's just have this bug resolved and I'll file bugs with all KDE playback applications...
> I guess this bug could be "half-closed". It's more that the mpeglib plugin > should be built into arts instead of the default playback routines. You cannot play mp3 with artsd without having mpeglib and mpeglib_artsplug installed. > The sound skipping when doing anything (moving windows around, changing > desktops, ...) is still there, but I'm thinking it's more of an issue with > the applications not feeding the sound daemon properly during those events. > My artswrapper is SUID root, BTW... Then artsd is either still not running with realtime-priority, your soundcard drivers suck or your buffer set for artsd is too small. I can have a load way greater than 1.0 without artsd skipping as long as the data floats in fast enough (for me streaming mp3 over a shoutcast-server in my LAN is the most reliable source, I cannot make noatun skip when playing mp3 that way) > If that is the case and can be confirmend by a qualified source, let's just > have this bug resolved and I'll file bugs with all KDE playback > applications... It has almost nothing to do with noatun, juk or amarok as these are just the graphical frontends to artsd.
I have the same problem as described above. I cannot play any mp3 file (others not tested) without a music skip of 1 sec about all 20 seconds. Arts CPU load is about 2%, but it is not possible to listen to music with any arts using program. Real-Time priority, maximum sized buffers and suid root artswrapper, nothing helped. I use KDE 3.2.1 SuSE RPMs. I have a standalone Creative Soundblaster card. I also recognized that during the skip there is always a hard drive access, Perhaps this helps.
CVS commit by wester: Fix performance of builtin gsl ogg player, by - upgrading the gsl data cache to the new beast CVS version - adding code to the data cache which copies overlapping sections from the last cache node, instead of redecoding, which eliminates the expensive vorbis backward seeks - tuning the data cache block size to a sensible value CCMAIL:61737-done@bugs.kde.org CCMAIL:80157-done@bugs.kde.org M +7 -2 gslschedule.cc 1.23 M +164 -77 gsl/gsldatacache.c 1.8 M +1 -0 gsl/gsldatacache.h 1.4