Audio/video problem with CPU throttling

[wlw_wl]

Hello folks,

I have a major issue with, apart from thet, this great player.
The problem is that I get a slow motion video and the audio stutters when CPU throttling is enabled.
I have dual core 3.1GHz CPU running XP SP3, and because VLc playback barely uses any CPU, it slows down to about 778MHz.
If VLC needed more power to play a movie, it would get it.

I've read other topics with similiar problems, but mod's response:
"I fail to see why VLC should implement hardware-specific code for stupid hardware that don't want to use normal OS functions."
is complete rubbish. The throttling is done using "normal" OS functions, and if any app needs more power it just gets it, the CPU is set to 1.9GHz or to max 3.11GHz.
Why I'm starting this topic is because a movie playback does not require all the power CPU has, therefore running it on full throttle makes no sense.
I have no other multimedia app that has any problem with that and I'm sure it requires no "hardware-specific code for stupid hardware" because all the throttling is done on OS level, therefore a low level.
It seems like VLC takes those 778MHz, says to itself "oh it's not enough, but I won't say a word, just do as much as I can with it" and plays badly.
I do not understand this behaviour and I cannot see a reason for it, because it would indicate tha VLC has it's own internal kind of throttling that prevents it from using all the CPU power it has available.
It happens to other people on different Windows so it's not OS specific, it's not hardware specific (as throttling is not done by some custom driver but by the OS itself) and seemingly, it's only VLC specific.

And lastly, I'm not here to moan or to complain, I'd like some assistance to find possible solution for this issue, as neither I would like to abandon VLC nor to waste 50W on CPU for hours every day.

edit:
Well, I found (in the Microsoft Knowledge Base) that such a problem may occur because the application "cannot correctly capture timing information". So the VLC "thinks" that CPU is running at 3.1GHz while it's running at 778MHz? That would explain it... But it would mean that VLC is using some "wrong" method of capturing the timings.
However, they suggest:

If you are a developer who is using the RDTSC (Real Time Stamp Counter) instruction to compute timing, visit the following Microsoft Developer Network (MSDN) Web site for information about the QueryPerformanceCounter function:
http://msdn2.microsoft.com/en-us/library/ms644904.aspx

[VLC_help]

VLC already detects that
from src\misc\mtime.c

Code: Select all

#if defined( WIN32 ) /* on windows 2000, XP and Vista detect if there are two cores there - that makes QueryPerformanceFrequency in any case not trustable? (may also be true, for single cores with adaptive CPU frequency and active power management?) */ HINSTANCE h_Kernel32 = LoadLibrary(_T("kernel32.dll")); if(h_Kernel32) { void WINAPI (*pf_GetSystemInfo)(LPSYSTEM_INFO); pf_GetSystemInfo = (void WINAPI (*)(LPSYSTEM_INFO)) GetProcAddress(h_Kernel32, _T("GetSystemInfo")); if(pf_GetSystemInfo) { SYSTEM_INFO system_info; pf_GetSystemInfo(&system_info); if(system_info.dwNumberOfProcessors > 1) freq = 0; } FreeLibrary(h_Kernel32); } #endif } if( freq != 0 ) { LARGE_INTEGER counter; QueryPerformanceCounter (&counter); /* Convert to from (1/freq) to microsecond resolution */ /* We need to split the division to avoid 63-bits overflow */ lldiv_t d = lldiv (counter.QuadPart, freq); res = (d.quot * 1000000) + ((d.rem * 1000000) / freq); } else { /* Fallback on timeGetTime() which has a millisecond resolution * (actually, best case is about 5 ms resolution) * timeGetTime() only returns a DWORD thus will wrap after * about 49.7 days so we try to detect the wrapping. */ static CRITICAL_SECTION date_lock; static mtime_t i_previous_time = INT64_C(-1); static int i_wrap_counts = -1; if( i_wrap_counts == -1 ) { /* Initialization */ #if defined( WIN32 ) i_previous_time = INT64_C(1000) * timeGetTime(); #else i_previous_time = INT64_C(1000) * GetTickCount(); #endif InitializeCriticalSection( &date_lock ); i_wrap_counts = 0; } EnterCriticalSection( &date_lock ); #if defined( WIN32 ) res = INT64_C(1000) * (i_wrap_counts * INT64_C(0x100000000) + timeGetTime()); #else res = INT64_C(1000) * (i_wrap_counts * INT64_C(0x100000000) + GetTickCount()); #endif if( i_previous_time > res ) { /* Counter wrapped */ i_wrap_counts++; res += INT64_C(0x100000000) * 1000; } i_previous_time = res; LeaveCriticalSection( &date_lock ); } #elif USE_APPLE_MACH /* The version that should be used, if it was cancelable */ pthread_once(&mtime_timebase_info_once, mtime_init_timebase); uint64_t mach_time = date * 1000 * mtime_timebase_info.denom / mtime_timebase_info.numer; mach_wait_until(mach_time); #else struct timeval tv_date; /* gettimeofday() cannot fail given &tv_date is a valid address */ (void)gettimeofday( &tv_date, NULL ); res = (mtime_t) tv_date.tv_sec * 1000000 + (mtime_t) tv_date.tv_usec; #endif return res;

[wlw_wl]

Thanks for the answer, well, if it's not that then... what could be?

Forgot to mention, I have 1.0.1 Goldeneye.

[VLC_help]

Other path might be incorrect also. I can provide you a test build for simple hack if you want to test it out.