[vlc-devel] [RFC] revert Win32: always use the performance timers

[Steinar H. Gunderson]

On Thu, Dec 09, 2010 at 11:03:22PM +0100, Rémi Denis-Courmont wrote:
>> Please don't use RDTSC. They're not correctly updated across sleep states
>> on all processors (much less suspend/resume); they are _not in sync_ between
>> cores (so as your process is migrated, it can easily jump back and forth
>> -- a _lot_), usally do not respect CPU frequency scaling, and so on.
> Yes. And that's one of the suspected problem with the current code too.

Trust me, RDTSC is ten times worse than timeGetTime(). If timeGetTime() jumps
around, it's a bug somewhere (most likely some driver); if RDTSC jumps around
it's expected behavior. (I don't think you have much guarantees about
QueryPerformanceTimer() either. timeGetTime() is really the way you're
supposed to get a multimedia timer under Windows, TTBOMK.)

The main attraction of RDTSC is: It's very precise, and it's extremely cheap
to read (a few cycles; no need to jump to kernel mode). I don't think VLC
needs either.

> I fail to see how that could work. There are many scenarios where VLC needs
> a clock, yet it is not using "the" sound card. Besides, I suppose the sound
> card timer cannot be read directly, but can only be inferred from the audio
> hardware buffer state.

Correct -- it's not a viable option when not playing with sound.
I don't think there's a one-fits-all solution for timing, but I'm not very
experienced in this area, so I won't say anything for sure.

/* Steinar */
-- 
Homepage: http://www.sesse.net/