On Tue, 4 Dec 2001, Alexander R Angas wrote: > > 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. > > 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? > > 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. 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? -- http://www.clock.org/~matt
