> 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