I have the same problem, using KDE 3.3.0 on gentoo/ AMD64 (alsa 1.0.6, gcc 3.4.1). Using Amarok for the first time in a session, I get an ARTS CPU overload or ARTS simply crashes. If I restart ARTS after the crash, Amarok works. The same problem is visible with KMPlayer (MPlayer backend, ARTS output).

I can confirm this as well. It happens immediatelly when using just any sound-effect on amarok, or from the arts-panel. Same happens with other media-players.
And I'm also on gentoo-amd64 not using any agressive optimization flags

Not that this needs another confirmation, but I can add mine as well.

EMU10k1, mm-sources 2.6.8.1-r4, kde 3.3.0, gcc 3.4, amd64... 

My mixer properly identifies and alters the level for my Audigy but no sound comes out of it through arts, and I get tyeh cpu overload notification, and measia players crash...

Someone in this thread (http://forums.gentoo.org/viewtopic.php?t=217621&highlight=alsa+emo10k1) solved their cpu overload problems, and I have been trying to edit the c0onfigs to do so myself without success...

Compiling KDE with useflag "-xine" (not +) solves the problem for me at the moment.

Hmm, it is not really solved. Now I get this error randomly (1 of 3 reboots). Very annoying and very strange... 

i also have the same problem, however it only occurs for me when playing MP3's. OGG playback works fine, as does WAV. 

When reporting the log of "artsd -l0", you need to kill the old artsd first (killall artsd). The log above, is only telling me you had an arts daemon running already.

as discussed in the gentoo forums, http://forums.gentoo.org/viewtopic.php?t=217621
the problem can be partially resolved by compiling kdemultimedia without xine support, however the problem remains when noatun is used to play video.

additionally the system hangs immediately when arts is set to realttime priority, but this might be a different bug.

The output of "artsd -l0" (without realtime priority): 

benklop@shiney benklop $ killall artsd&artsd -l0
[1] 8407
artsd: no process killed
artsd version is 1.3.0
gsl: using Unix98 pthreads directly for mutexes and conditions
[artsd:  8408] SoundServerStartup --> got lock
autodetecting driver:
 - toss: 4
 - null: -1
 - alsa: 15
 - oss: 10
... which means we'll default to alsa
ALSA driver: default
buffering: 7 fragments with 1024 bytes (audio latency is 40.6 ms)
ALSA lib pcm_hw.c:549:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe
Closing ALSA-driver
virtualize StereoVolumeControl
ALSA driver: default
buffering: 7 fragments with 1024 bytes (audio latency is 40.6 ms)
ALSA lib pcm_hw.c:549:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe
audio format is 44100 Hz, 16 bits, 2 channels
addDirectory(/usr/kde/3.3/lib/mcop,)
addDirectory(/usr/kde/3.3/lib/mcop/Amarok,Amarok)
addDirectory(/usr/kde/3.3/lib/mcop/Arts,Arts)
addDirectory(/usr/kde/3.3/lib/mcop/Arts/Environment,Arts::Environment)
addDirectory(/usr/kde/3.3/lib/mcop/Noatun,Noatun)
addDirectory(/home/benklop/.mcop/trader-cache,)
Arts::MidiManager registered successfully.
[artsd:  8408] SoundServerStartup <-- released lock
UnixManager: got notifyIO
socketconnection created, fd = 8
findPort(outleft)
have 4 ports
done
result 74
connect port outleft to left
findPort(outright)
have 4 ports
done
result 74
connect port outright to right
search playobject, mimetype = video/x-msvideo
creating xineVideoPlayObject to play file
findPort(left)
have 2 ports
done
result 10
connect port left to inleft
findPort(right)
have 2 ports
done
result 10
connect port right to inright
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
UnixManager: got notifyIO
socketconnection created, fd = 14
search playobject, mimetype = audio/vorbis
creating akodeXiphPlayObject to play file
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
akode: opening /usr/kde/3.3/share/sounds/KDE_Window_Open.ogg
findPort(left)
have 3 ports
done
result 10
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
connect port left to left
findPort(right)
have 3 ports
done
result 10
connect port right to right
akode: play
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,
fifo_audio_out: 1152 sample(s) discarded.
fifo_audio_out: blocked for more than 66 ms,

---------------------------------------------------------------
this last message is repeated until a point where the cpu is overloaded and artsd crashes.
note that this was created by playing a video file, however the same errors occur while playing an audio file through xineAudioPlayObject.
also note that video was still working correctly, there was just no audio.

Also happening to me (fresh install of amd64)... does not happen when logged in as root.

Same issue on a x86 box since >=Arts-1.3.0 under high load with arts having real time priority and 8 milliseconds buffer.

The xine plugin seems to have 64bit problem in the audio-buffer.

I compiled ARTS without xine support and still had that problem IIRC. But it seems to be fixed when routing ARTS through a dmix plugin (not directly accessing hw:0) - it's very hard to test, but I use that setup since yesterday and had no crash (yet)...

Interesting... What sound chipset do you have?
I think i will try to install dmix tomorrow then, see if i can confirm this solution.

Thanks!

Willie Sippel <willie@froq.net> wrote:
__________
>------- You are receiving this mail because: -------
>You are a voter for the bug, or are watching someone who is.
>        
>http://bugs.kde.org/show_bug.cgi?id=88474        
>
>
>
>
>------- Additional Comments From willie froq net  2004-12-02 11:23 -------
>I compiled ARTS without xine support and still had that problem IIRC. But it seems to be fixed when routing ARTS through a dmix plugin (not directly accessing hw:0) - it's very hard to test, but I use that setup since yesterday and had no crash (yet)...

I'm using a Terratec EWX24/96 (ice1712), with ALSA 1.0.7 drivers and libs. And it really seems to be fixed using dmix, had not a single glitch anymore... 

Apart from the random cpu-overload messages I keep getting those:

AudioSubSystem: rBuffer is too full
AudioSubSystem: rBuffer is too full
(The previous message was repeated 2163 times.)
xrun!!

AudioSubSystem: rBuffer is too full
AudioSubSystem: rBuffer is too full
(The previous message was repeated 485 times.)
xrun!!

AudioSubSystem: rBuffer is too full
AudioSubSystem: rBuffer is too full
(The previous message was repeated 17 times.)
xrun!!

AudioSubSystem: rBuffer is too full
AudioSubSystem: rBuffer is too full
(The previous message was repeated 189 times.)
Synth_RECORD: detaching
Closing ALSA-driver
Synth_PLAY: closing audio fd

This is happening here when it starts to hammer the CPU.  I am getting screens full of this message.

Is there actually any investigation going on regarding this bug?  I am at KDE 3.4 now and arts is still very unstable.  As soon as I try to use arts builder or any other arts application I am getting this CPU overload error.  So far I haven't found a working solution and I don't see any comments from the dev team on this problem.  Anyone there?

on gentoo-amd64 mailinglist there was a thread about that, as a workaround is described to change sound system from ALSA to OSS in kcontrol -> sound system. even if you use alsa (as i do).

i hadn't any crashes since that.

Or do what I suggested: run ARTS via the ALSA dmix plugin. I use that setup since 12 2004, and had not a single crash since. 

ALSA should really enable dmix by default...

Created attachment 11112 [details]
Handle the XRUN reported by snd_pcm_avail_update

This bug happens very often to me. I'm running Debian amd64, experimental gcc4 distribution. Currently with kernel 2.6.12-rc3-mm3, but the bug was occuring with older kernels too. I'm using arts with output device set to ALSA. I've found that I can reproduce the bug at will by:
killall -STOP artsd && sleep 1 && killall -CONT artsd
This always puts arts into the CPU spinning loop.
I have discovered that the problem is caused by an XRUN, which is not handled correctly in arts. arts uses snd_pcm_avail_update to ask ALSA how many frames it can write. However, when an XRUN occurs, snd_pcm_avail_update will return -EPIPE. This condition is not handled in arts. I have attached a patch. With this patch I can no more reproduce the bug.

I also have this bug on my AMD64 box with KDE 3.4.0 and Linux Kernel 2.6.11.10 and ALSA 1.0.8/1.0.9rc3.

Mostly it works just fine but somteime I get this overload message and now soundand artsd is using 100% CPU.

And this happans always when I start up KDE. When the desktop comes up artsd is using 100% CPU and after some time it gets killed and I get the CPU overload message.

Is anyone working to fix this annoying bug?

I have tried the patch from Michal Schmidt and on my system the patch solves all problems regarding lockups and cpu overloads. Thanks for this patch, Michal. Maybe it should be merged upstream (in the official arts distribution)?

How can I use this patch to test it? Does it work with KDE 3.4.1?

Ok after a reading some manual pages I managed to patch arts in KDE 3.4.1 and recompile it. So far I don't get the 100% CPU problem anymore. Not at startup and not during normal KDE use. So I guess the patch is working. It would be nice to see this patch in official KDE release.

SVN commit 423127 by carewolf:

Commiting fix for checking xrun in pcm_avail_update. 
Commited based on user feedback as I do not have 64bit system.
BUG: 88474, 106569


 M  +27 -2     audioioalsa9.cc  


--- trunk/KDE/arts/flow/audioioalsa9.cc #423126:423127
@@ -260,15 +260,40 @@
 
 int AudioIOALSA::getParam(AudioParam p)
 {
+	snd_pcm_sframes_t avail;
 	switch(p) {
 
         case canRead:
 		if (! m_pcm_capture) return -1;
-		return snd_pcm_frames_to_bytes(m_pcm_capture, snd_pcm_avail_update(m_pcm_capture));
+		while ((avail = snd_pcm_avail_update(m_pcm_capture)) < 0) {
+			if (avail == -EPIPE)
+				avail = xrun(m_pcm_capture);
+#ifdef HAVE_SND_PCM_RESUME
+			else if (avail == -ESTRPIPE)
+				avail = resume(m_pcm_capture);
+#endif
+			if (avail < 0) {
+				arts_info("Capture error: %s", snd_strerror(avail));
+				return -1;
+			}
+		}
+		return snd_pcm_frames_to_bytes(m_pcm_capture, avail);
 
 	case canWrite:
 		if (! m_pcm_playback) return -1;
-		return snd_pcm_frames_to_bytes(m_pcm_playback, snd_pcm_avail_update(m_pcm_playback));
+		while ((avail = snd_pcm_avail_update(m_pcm_playback)) < 0) {
+			if (avail == -EPIPE)
+				avail = xrun(m_pcm_playback);
+#ifdef HAVE_SND_PCM_RESUME
+			else if (avail == -ESTRPIPE)
+				avail = resume(m_pcm_playback);
+#endif
+			if (avail < 0) {
+				arts_info("Playback error: %s", snd_strerror(avail));
+				return -1;
+			}
+		}
+		return snd_pcm_frames_to_bytes(m_pcm_playback, avail);
 
 	case selectReadFD:
 		return -1;