severe audio stutter - alsa amarok1.2 intel8x0 2.6.13-r3

[feralchimp]

The stuttering seems more related to disk activity than high CPU load, and under both (like a compile or eclipse CVS pull) the audio stutter is severe to the point of total unusability. I suspect this can be addressed with the right kernel configuration, because the problem seems particularly bad after my latest kernel rebuild.

My preemption settings for the latest kernel rebuild are "Desktop" (voluntary kernel preemption), and preemption of the Big Kernel Lock is currently DISABLED. Furthermore, as my laptop is a singleproc Pentium-M, I disabled SMP support in the kernel. I also have the HPET support enabled, and the timer resolution set to 1000Hz.

The USE flags at my last "emerge -upDN world" action were as follows:
USE="acpi alsa -apm -arts avi berkdb bitmap-fonts crypt cups eds emboss encode fortran foomaticdb gdbm gif -gnome gpm gstreamer gtk gtk2 imlib -ipv6 jpeg kde libg++ libwww -mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl -oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib"

It's not really clear to me why big kernel lock preemption or a lower-resolution timer would help (or further exascerbate) the audio stutter issue. I'm also wondering whether (despite the high number of anti-aRTs posts) having "-arts" specified during the latest amaroK build could be the problem. I'll continue flipping various switches in the meantime, but if anyone could drop some basic science on this topic I'd appreciate it.

Oh, one more thing...I also have a pretty serious cursor lag issue during disk-intensive ops. During a compile, using the mouse in KDE can be like flying a drunk duck by radio control.

-Jared

[feralchimp]

I noticed on boot something about polling the card, then setting the sample rate to 48000. Is it possible that something in the chain (amaroK, GStreamer, artsink) is trying to convert my audio streams from 44100 to 48000 on the fly (and stuttering because the process that does that work is non-realtime)?

[feralchimp]

okay, more thinking out loud. Back when I had amarok compiled with "arts" in my USE flags, I remember being able to select (and configure settings for) arts as the default amarok output engine. One of those settings had to do with the default sample rate, which I believe was originally set to 44100. Furthermore, I remember issuing a command early on in my gentoo days (a week ago:) to make arts run with realtime priority.

So I'm pretty sure what I want to do (kernel preemption tweaks notwithstanding) is to replace "-arts" with "arts" in my USE flags, emerge -uDN world, go back into amarok and select arts as my output engine, set the default sample rate to 44100, and hunt around for the magic "make arts run realtime" command in the forums. I'll post results tonight or tomorrow.

[feralchimp]

emerge -upDN world with "arts" in the USE flags seems to have helped, possibly because of how KDE interacts with the arts server. That is, by setting the default sample rate to 44100, telling the arts server to run with realtime priority, and sizing a playback buffer.

I've heard that aKode does somewhat smarter buffer management, and I currently have amaroK running well with the aKode engine. I haven't tried either during a heavy batch compile yet, so I can't recommend one over the other.

So I'm glad that my sound is working better, but I wish I actually knew why instead of depending on side effects of side effects. Any thread recommendations?

[feralchimp]

for amarok 1.2 during large compile,
where "<" == "seems to skip/stutter worse than"

aRTs engine << aKode < aRTs engine set to run with realtime scheduling

[as root, go to wherever artswrapper lives]
chmod u+s artswrapper
then restart artsd via the KDE control center.

this whole ordeal is helping me appreciate some of OS X's imposed pokeyness. steady tunes uber alles!