On 08/08/2012 03:49 PM, David C. Rankin wrote: I just timed how long artsd stays at 10% CPU after the last sound event. It is right at 60 sec. So arts is triggered, and for some reason it stays resident doing its job and doesn't unload for 60 secs or so. Check your box with top running. Trigger a sound event. My artsd immediately jumps to 10% and stays for the timeout period, then drops back off to 0%. We have to be able to fix that. It should do its job and then drop off immediately rather than taking a minute to release the cpu. You have to have sound-events configured. I just use shade-up/shade-down with the middle-mouse. The cpu use is 100% repeatable on my install. No pulseaudio. What to check? Can I crank up logging somewhere to see what is going on? -- David C. Rankin, J.D.,P.E.

Le 08/08/2012 22:53, Slávek Banko a écrit : Hello, my artsd is always at ~0% even when playing sound. But I have a different problem: all the TDE sounds are delayed from about ~2sec, which is very very noticeable. Sounds play smoothly (no stutter), but they start playing long after the corresponding action has been done. Any clue on this ? Francois

Le 08/08/2012 23:29, Timothy Pearson a écrit : Right, by disabling pulseaudio, arts is much more responsive :-) Alas, I need pulseaudio so I cannot leave it disabled. BTW, I think that this lag is very huge ! I can understand that having several chained sound servers may cause a little delay, but here, we're talking about 2 seconds ! Francois

On 08/08/2012 04:26 PM, Francois Andriot wrote: Yes, I see this all the time in my Arch installs, it is due to pulseaudio on my box. I have seen some improvement by moving all of the pulseaudio* files out of /etc/xdg/autostart. This is not a complete solution. OpenSuSE has done a good job integrating atrtd with pulseaudio. I do not notice near the delay on suse that I do on Arch. I think Ilya (or somebody) must patch the pulseaudio-kde file to work better with kde3. I suspect the native pulseaudio-kde file is for kde4 only. I have noticed much better sound performance from 3.5.13-sru on my virtualbox installs. On that install Arch Linux guest in virtualbox, sound is perfect. There is only libpulse 2.1-1 alsa-lib 1.0.25 That is the way to run. You can check if pulse is running with 'ps ax | grep pulse' On most installs, I see: 16:41 providence:~> ps ax | grep pulse 1874 ? S<l 0:00 /usr/bin/pulseaudio --start --log-target=syslog 1886 ? S 0:00 /usr/lib/pulse/gconf-helper On those installs, I see exactly what you describe. Sound works, but is delayed by a second or two, but otherwise plays. However, if you try to play 2 sound files close together (shade-up/shade-down) then then second sound file does not play. It was explained to me that both arts and pulse are attempting to control the same hardware and end up in conflict that causes the delay. This needs to be fixed by some smart person because if you have gnome + tde installed you are going to have pulseaudio on the system. We need to figure out how to work with it rather than just saying 'uninstall pulse'. suse does it. I have pulseaudio running on my laptop with kde3 and sound is much less delayed than on Arch. Maybe suse lowers a timeout threshold or something like that. If you just have tde installed, then I think the correct answer is to remove pulse. If you have other desktops that need pulse, then I think we need to figure out how to configure pulse so it works well with arts. There is useful info on the Arch wiki about pulse and its config: https://wiki.archlinux.org/index.php/PulseAudio I have worked through it, but there is a LOT of information on pulse referenced from external sites that also needs to be digested to understand how pulse works.