> It does sound a bit slow on my machine. The code looks fine, other than > you are specifying a 2ms timer accuracy to timeSetEvent and you really > want 1ms.
Sure, just left it at 2 because it sounded the same as 1 on my machine. > 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? > 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? > 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. Thanks Matt, Alex.
