[Qt-interest] QTimer on Windows in Unreliable for Small (16ms - 30ms) Delays

[Josiah Bryan]

Pau Garcia i Quiles wrote:
> We have seen issues with QTimer on Windows, too, when you ask for a
> tiny interval or the system is under high load. The reason for this
> broken behavior is QTimer essentially counts events on Windows. A
> better approach would be to call GetTickCount or
> QueryPerformanceCounter. On Unix, QTimer uses clock_gettime, which
> works fine.

Hmmm...interesting. I'll have to mull that one over.

> For now we are using ACE timers (
> http://www.cs.wustl.edu/~schmidt/ACE.html ) instead of QTimers where
> we see problems.

Could you provide any code examples or quick snippets to illustrate the 
use of ACE timers in Qt-based code? It would help a lot!
> 
> That being, said, your problem is probably not due to QTimer but due
> to the latency of the Phonon backend (DirectX under Windows).
> Different backends behave different: some have a longer latency than
> others. Some will support a feature, others won't. This very issue,
> failing to playing very short media files, we have found to happen
> with DirectX (Windows), Xine (Linux), GStreamer (Linux) and VLC
> (Linux). VLC behaved a bit better than the others did but still failed
> in some cases.

I'm actually not even using Phonon - using ffmpeg directly (libavcodec 
and friends) to decode the video streams, buffer the frames using 
QQueue<QFFMpegVideoFrame>, and render the frames with appros delays 
calculated from the pts of each frame. So, in this case, DirectX or Xine 
or GStreamer aren't even being touched. Of course, since ffmpeg and 
friends are the backend for VLC, thats a different story - but so far, 
on linux, I have not experienced a single problem with the timers like I 
have on windows.

I would, though, appreciate any code samples you could spare on ACE 
timers - I'll gladly explore that route.

Thanks!
-josiah