CPU Usage pegged at 100%
Brought to you by:
peoplestank
Menu
▾
▴
#56 CPU Usage pegged at 100%
When I start up osw.exe, a default patch document is
created. I am able to add transform boxes, message
boxes, connect line.
Even with a blank patch document, cpu is pegged at
100%. I am running this on a laptop, 1.4 GHz Mobile
Pentium (Dell D500 laptop) with 512 MB RAM. Killing
osw.exe or closing the patch document reduces CPU
back down to under 5%. Running Windows XP Home
edition.
Seems to me like something is really wrong.
Logged In: YES
user_id=588127
one of the developers told me, that this is normal and does
not slow down other programs. what i wonder: does it
influence the battery uptime of a laptop?
as it is very confusing, that osw seems to eat all available
cpu time, i also would consider this as a bug. isn't there a
way to avoid this? (this question goes to the developers)
Logged In: YES
user_id=943562
Following up on smoerk's comment -
100% cpu usage doesn't seem normal to me. Windows media
player runs about 5% cpu usage (minimized) - upto about
15% if you display the fancy graphics window. (playing
a .wma file from hard disk).
Logged In: YES
user_id=588127
no, it doesn't seem normal, but it should not slow down
other applications. osw only consumes the idle time, if
you're running other applications, osw will not run at 100%
anymore.
wait... ah, i found the explaination from amar:
The way OSW utilizes CPU under Windows when audio is on is
to take as much CPU as the operating system will allow (thus
it looks like 100% if you open the CPU meter). However,
other applications will be able to run and grab their share
of CPU, and OSW's share will diminish accordingly.
i still don't know, if osw consumes real CPU power
(electricity, battery) or if the CPU meter just shows the
wrong CPU uasge.
Still, this is confusing and an a fix would be nice (if it's
somehow possible).
Logged In: YES
user_id=315707
Actually, this is currently the expected behavior, with OSW
consuming "whatever CPU is available" in order to support
the requirements of audio quality, responsiveness to events,
and scaling to multiprocessor environments. OSW not
actually using all of the CPU, simply what is not in use by
other applications or the system - and it should not prevent
other processes from using the CPU. I agree, the meter is a
bit disconcerting, and we are looking into ways to address
that. A method to force a thread to yield would likely solve
the problem, but the obvious use of SleepEx for this either
creates an unacceptable 1ms delay or fails to yield.
Logged In: YES
user_id=315707
I have just checked in a fix to this bug. CPU now reports
much less than 100% and scales with patch complexity.
Logged In: YES
user_id=315707
I have just checked in a fix to this bug. CPU now reports
much less than 100% and scales with patch complexity.