RE: [GD-Windows] WaitForSingleObject sleep granularity

[Andy G. <an...@mi...>]

WFSO and Sleep() both have the same granularity - it's based on the
current hardware timer interrupt rate. This varies depending upon the
OS, number of CPU's and if you have foreground task priority enabled in
server OS's. This varies from 1, 10 or 15ms. You can use
timeBeginPeriod(1) to set the hardware timer at 1ms, but I would advise
against it. Interrupts are slow, dealing with them is slow, and they
really mess with laptops ability to go to sleep or reduce power when
ever they can.

Thread priorities can also really start to mess things up, and so can
having threads that hog the cpu and never call any OS blocking APIs or
Sleep(0)'s.

Because threading and scheduling has altered over the years its best not
to try and hard code some system that only just works, its way better
off making sure you don't need the sorts of resolutions that may cause
problems. A WFSO for 60ms should be just fine (even without increasing
the timer frequency) - if this thread does very little work (like
trigger a blocking file read) and it does not have critical sections
around things that will cause other threads to stall it should run just
fine. I see a lot of problems in architecture like this caused by people
putting critical sections around code that contains OS blocking API's
like file reads - this often causes other threads that use the same
critical section to now also be stalled for the length of the disk read.

Try putting some timer code around bits of your program and see where
you are being blocked or stalled when the clicks occur.

Andy.


-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Tuesday, April 02, 2002 8:54 AM
To: Brian Hook; gam...@li...
Subject: RE: [GD-Windows] WaitForSingleObject sleep granularity


You didn't say what OS (98/NT/XP/...).

I've found the Windows scheduler to be very jittery with a minimum
useable
resolution of 10 milliseconds or so for a highest-priority thread.
However,
even so you may suddenly get 100 millisecond drop-outs. These numbers
are
a bit better on NT based kernels, as their device drivers are somewhat
more
well behaved.

There's also the problem that many consumer audio cards just don't want
to
deal with audio buffers smaller than 20 milliseconds, so any attempt to
go
lower than that will fail, and even higher "target latencies" may suffer
from being quantized to whatever buffer size the card uses internally
(yes,
there are lots of cards that use a fixed size granularity!)

Your best bet is to write a program which times the MAXIMUM difference
between when you want to wake up and when you actually wake up, and run
it
while you do other things on the machine (FTP, surf the web, WinAmp,
play
Quake, whatever) and see what comes out. Plot this maximum number over a
minute of activity against the different thread priorities and different
Windows OS-es and different sound cards to give you enough data to make
a
good decision.

Cheers,

				/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Monday, April 01, 2002 4:56 PM
> To: gam...@li...
> Subject: [GD-Windows] WaitForSingleObject sleep granularity
>
>
> Any ideas what the sleep granularity on WFSO is?  Whilst working on my
> audio mixer I've found that I'm running into some clicking/popping
which
> _might_ be related to the WFSO that I do in between buffer fill-ups.
> With a 250ms buffer I tend to WFSO for about 60ms...any chance that
the
> WFSO gets exploded into something horrendously huge?
>
> Thanks,
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555