> 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