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

[Rémi Denis-Courmont]

   Hello,

On Friday 10 December 2010, Steinar H. Gunderson wrote:
> 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.)

As far as I know, QueryPerformanceTimer() is supposed to be uniform across 
processors, except on buggy chipsets (read: Microsoft does not work around 
chipset bugs). Otherwise, why would the function exist anyway...

> > 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.

We are not looking for one-fits-all. We are looking for a monotonic clock that 
has decent precision and is uniform across all processing units, like the 
POSIX monotonic clock on Linux.

Every body knows that this is going to suck for audio playback due to drift 
between the clock and the audio hardware. But VLC has learned to cope with 
that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/