8 Aug
2012
8 Aug
'12
9:56 p.m.
On 08/08/2012 03:49 PM, David C. Rankin wrote:
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
On 08/08/2012 03:41 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. 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.