On 08/08/2012 03:49 PM, David C. Rankin wrote:
On 08/08/2012 03:41 PM, David C. Rankin wrote:
All, Slavek,
In 3.5.13-sru, the artsd process is continually taking between 8 and 11 percent of the CPU. That is high compared to my other installs of 14.0. Is anybody else seeing this? The sound is working though, so I'm pleased there. (that has always been hit or miss) What to check to see why artsd is so greedy?
This may be normal, but when any sound event is triggered, I get the following in my ~/.xsession-errors file:
OggS-SEEK: at 0 want 89080 got 85568 (diff-requested 89080) OggS-SEEK: at 88640 want 520 got 0 (diff-requested -88120)
Does that make any sense?? After a few minutes, artsd does drop off to about 0.3% cpu which is what I normally expect to see, but I don't understand why it hovers around 10% after the sound finishes playing.
Let me know if you can think of anything, otherwise, I'll just keep an eye on it.
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.
Arts actually stays loaded on purpose, to minimize startup-related latency on the next sound event. There is a configuration option in kcontrol to set the unload delay IIRC.
Tim