On Fri, 21 Dec 2001, Alexander R Angas wrote: > > I'm working on FreeSCI for a few hours in the soundserver if you'd like to > > meet me on IRC :) > > I would but unfortunately I'm not even supposed to be using the phone line > now. Sorry! I tried putting timeSetEvent() between timeBeginPeriod(1) and > timeEndPeriod(1) but it didn't make any difference. > > Anyway, hope you can do something! Good luck.
Actually, I realised that the timer resolution is specified in timeSetEvent as the second parameter, so the timeBegin/EndPeriod calls were redundant. Here are my findings: Using callbacks or pulsing the event, the latency is not only too high, but it is not consistent. There is no way to measure the latency of a machine and then adjust for it, because it is fairly inconsistent. So, what might work is a hybrid approach: we get events that tell us when to start polling and when to stop polling. We can poll using QueryPerformanceCounter (or add the old usleep.c back into the project) for greater than microsecond resolution on most CPUs. We could also take another look at the DirectX 8.x high resolution timers, but I'd rather not put that burden on users. This article provided a lot of insight: http://www.codeproject.com/system/simpletime.asp After reading this, I realised that the Sleep(1) in the polled_ss_win32.c would mean it would probably sleep too long upon startup in most instances! Changing it to Sleep(0) makes FreeSCI use 99% CPU, but does seem to help accuracy. I'm not really sure what to do here.. opinions from the list? -- http://www.clock.org/~matt
