[vlc-devel] [RFC] revert Win32: always use the performance timers
remi at remlab.net
Fri Dec 10 01:09:43 CET 2010
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
More information about the vlc-devel