I might have figured out the cause of the problem.
When emulation is paused, do you always undo the effect of any previous DwmEnableMMCSS(), AvSetMmThreadPriority() and AvSetMmThreadCharacteristics() calls?
From the
MSDN Multimedia Class Scheduler Service page:
Quote:
The MMCSS settings are stored in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
...
The key also contains a subkey named Tasks that contains the list of tasks. By default, Windows supports the following tasks:
...
Each task key contains the following set of values that represent characteristics to be applied to threads that are associated with the task.
...
Clock Rate REG_DWORD A hint used by MMCSS to determine the granularity of processor resource scheduling.
Windows Server 2008 and Windows Vista: The maximum guaranteed clock rate the system uses if a thread joins this task, in 100-nanosecond intervals. Starting with Windows 7 and Windows Server 2008 R2, this guarantee was removed to reduce system power consumption.
|
On my system all tasks in the registry have a Clock Rate value of 10000 (i.e. 1000000ns = 1ms). Thus when you call DwmEnableMMCSS(), AvSetMmThreadPriority() or AvSetMmThreadCharacteristics() the timer resolution is changed to 1ms.
On a related note, how about adding an option to not call DwmEnableMMCSS(), AvSetMmThreadPriority() or AvSetMmThreadCharacteristics()? If the user is using some Workbench app (not a game or demo) and not playing sound, they may prefer power saving over smooth-as-possible graphics updates.