> > > I asked the CTO of my company how he would solve this problem. What we can > > > do it use timeSetEvent or another waitable timer to signal us at 14 or > > > 15ms. Then, we can poll a high resolution timer (I would prefer > > > QueryPerformanceCounter since it doesn't require DX8) for the remainder > > > and process the event. Because we are only polling for the last bit of the > > > cycle, CPU usage should remain fairly low. We'll have to actually > > > implement this to see how it works out, though. > > > > This idea is welcomed but perhaps wouldn't work too well. What value for > > timeSetEvent() do you use? Some machines (like mine) might need the value to > > be as low as 8 or 9, while yours might work fine at 14 or 15ms. Also, as you > > would be polling the counter, what would you do to take the load off the CPU > > during this time? > > Even if it was as low as 8 or 9, polling for half of the time instead of > the full time would be better. You could do a "benchmark" upon > initialization and check the latency of the timer, then set the prameter > to timeSetEvent accordingly. Since the polling would only happen for 8ms > (at maximum), CPU usage should still be relatively low.
Two things I didn't explain properly though. Firstly, as I said, for you the value might be 14 and for me 8. Someone else might need a value of 4 or 10 or virtually anything in the range 0-16. Sounds messy. The second thing is whether there is a possibility of some jerkiness in the graphics where polling starts and the event stuff stops. That may not be noticeable at such a fraction of a second though. > > > Something else -- have you tried using TIME_CALLBACK_FUNCTION instead of > > > the Win32 Event stuff? The event-based stuff will have the same latency > > > problems -- but I don't think the CALLBACK_FUNCTION would. I tried doing a > > > simple change, but got really weird results. > > > > > > Let me know your thoughts on this and if you already tried it. > > > > I have tried it but got the same results. Maybe running Quantify over the > > driver would tell us something? > > Okay, that is *very* odd. Using a Callback doesn't have the latency of > signalling (and reacting to) a win32 Event. The Callback should sound > noticably better in this respect. This makes me think something else is > wrong. I'll keep looking and see if I notice anything obvious. > > What function were you using for the callback in the timer? Hmmm OK, I can't remember it was quite a while ago. I'm just investigating that now (using timeSetEvent() with a callback). > > > I noticed you fixed some soundserver synchronization problems in the event > > > soundserver -- do any of those apply to the polled soundserver as well? > > > > Yes but I _think_ only the one during initialisation. The two Win32 drivers > > need comparison. > > I started doing this and addded the thread_started synchronization to the > polled soundserver. I didn't notice too much of a difference, though. There shouldn't be too much of a problem under the polled sound server, it's a 'better safe than sorry' thing. Need to check the Sarien code to make sure it's being done correctly though. > Another minor bug I noticed was that emap[] is defined one element too > small for the assignments that are being made to it. Is it right to extend > it +1, or is it being "filled" wrong? Nice find - it wasn't being filled correctly. That will be in my next CVS commit. Thanks Matt, Alex.
