Version: 2.0.1 (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages The juk gui becomes incredibly sluggish once a song is playing. Sometimes, the gui controls are only reacting after one to two seconds and have to be clicked two or three times till it reacts. Machine is Athlon XP 2000+ with arts-output consuming around 9% of CPU, the machine is idle, otherwise. I guess the player is running in the same thread as the gui. Please move the player into an extra thread, separated from the one the gui is running in.
I'm pretty sure this is the standard Debian dependency problem. aRts will play stuff without mpeglib installed, but not very well. Please install mpeglib and things should be much better.
Installing libarts1-mpeglib does only help a little bit when it comes down to slugginess. The cpu usage of artsd reduces from 9% to 1% with libmpeglib. But the real problem seems to be the combination of artsd and alsa+dmix. As soon I switch artsd to "Threaded Open Sound System" the cpu usage drops to 0.3% for artsd and Juk becomes perfectly usable. Should I file a bug report on arts or alsa?
Artsd seems to block till the dmix buffer has emptied. Changing the dmix setup in /etc/asound.conf from pcm.dmixer { type dmix ipc_key 1024 ipc_key_add_uid true slave { pcm "hw:0,0" period_time 0 period_size 4096 buffer_size 16384 rate 44100 } bindings { 0 0 1 1 } } to the insane buffer size of 256 bytes pcm.dmixer { type dmix ipc_key 1024 ipc_key_add_uid true slave { pcm "hw:0,0" period_time 0 period_size 128 buffer_size 256 rate 44100 } bindings { 0 0 1 1 } } makes Juk respond almost immediately, but triples the CPU load of artsd.
Ah, sorry -- yeah I didn't actually understand what you were getting at earlier until this post (and the Debian not installing mpeglib issue comes up so often that it was a reflex). Honestly I don't really know very much about dmix -- but I would presume that it's possible to terminate a stream even once its entered the buffers. But this is either an aRts or ALSA issue, so I'm moving it there. (Oh, and one thing I forgot to respond to in your original post -- JuK doesn't do any decoding or playing in process when using the aRts backend; it simply sends requests to artsd to play something and gets feedback from there.)
It is another known problem. The OSS-emulation layer in ALSA sucks, using the TOSS-driver in aRts is a workaround for bad hardware and also helps in this case. But the best solution is to use the ALSA-driver if you have ALSA. Be aware that to use dmix with aRts you need KDE 3.2.2 or later. Using a newer aRts also changes the default driver from OSS to ALSA.
Allen, I **am** using alsa + dmix + arts alsa output with kde 3.2.2. I was just experimenting with the threaded oss driver. The hardware is in no way bad, it's a nvidia nforce2 soundstorm chip. The sluggishness happens with the above combination, but not with the threaded oss and not with the oss output arts module. The sluggishness only goes away by reducing the dmix buffersize to the small value of 256 bytes. So I guess it is either a dmix or artsd bug. I have not noticed a similiar behaviour with xmms and the alsa output module. Arts version is 1.2.2. Alsa is from kernel-2.6.5 and the alsa-utils version is 1.0.3.
Okay, that changes things: aRts do not block until the buffer is empty as you suggest, but it could block for an entire period. You could improve things by keeping the period size small (512 or 1024 bytes) and still have a large buffer. But seriously it sounds like one of the intermediate problems I had while fixing dmix. Can you tell me the exact installed versions of aRts(most like 1.2.2-1) and libasound2? Also does downgrading libasound2 help?
ii libarts1 1.2.2-1 aRts Sound system ii libasound2 1.0.4-1 Advanced Linux Sound Architecture I cannot downgrade to the woody version, because the whole kde 3.2.2 will get uninstalled. I do not have any older sarge alsa version at hand, too. I already decreased the buffer size to 256 bytes. 512 is not small enough. See http://bugs.kde.org/show_bug.cgi?id=81095
Okay I managed to reproduce. At least it is already fixed in CVS-HEAD, so I am back-porting a few fixes. If I send you a patch can you compile and test a new version of aRts?
Yes, I can.
Created attachment 5905 [details] Dmix interactivity patch
Forgot some comments: This patch is supposed to be applied to in the arts/flow folder. It fixes the problem here, but I would like to know if it helps for you too.
Yes, this patch perfectly fixes this problem for me. Should I file a bug on libarts1 and append your patch as fix on bugs.debian.org?
Yes, it's probably a good idea. I am going to commit it to KDE CVS now, but that wont make it to an official release before KDE 3.2.3
Filed the bug report + patch for debian/libarts1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247905 Allan, thanks a lot!