gamedevlists-windows

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

RE: [GD-Windows] WaitForSingleObject sleep granularity

[Brian H. <bri...@py...>]

> 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'm using critical sections to guard access to shared data (e.g. the
input audio stream), but other than that, it's pretty vanilla.  The gist
of the overall mixing loop is pretty simple, basically it just sleeps
via WFSO and then wakes up to fill a buffer occasionally.

I have some debug code that prints out the amount of time elapsed since
it woke up, and this seems to be the source of my chokage.

Specifically, with a 100ms buffer I ask for delays of 25ms.  @
22KHz/16-bit, this means that every time I wake up I should have
approximately 2205 bytes to write to the buffer.  During steady state I
get a measured delay of ~2750 bytes.  Not a big deal, just a couple more
ms, and not enough to cause an underflow.

However, when playing my "splash" sound at startup (which overlaps some
file IO), I get huge spikes in this delay, on the order of > 8000 bytes,
which corresponds to much larger delays in the WFSO.

So something is funky is happening as a result of the file i/o, but the
critical sections I'm using aren't wrapping around anything that would
cause heinous blockage (at least, that I can see).  So I'm not sure what
else might be happening here.

One the file loading is over, everything settles down and it gets all
happy and fine again.  If I remove my SetProcessAffinityMask call so
that both processors can be used, the weird delays disappear.

-Hook

RE: [GD-Windows] WaitForSingleObject sleep granularity

[Brian H. <bri...@py...>]

Just as an update, it turned out to be a thread priority problem, not a 
granularity or performance problem.  By bumping up the audio thread to 
HIGHEST or TIME_CRITICAL, all the stuttering went away.

Brian