Bug 81095

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!