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