> > As far as the accuracy of the timer, the problem definitely seems to be with > > timeSetEvent() not living up to its promises. Even when using do_sound() as > > the callback function (a method that would cause synchronisation problems > > BTW), the problem is not noticeably improved.
I did think of a solution - write an algorithm that focusses in on the correct value for timeSetEvent() based on the values from something reliable like GetTickCount(). Once it gets within a certain delta, then we have the correct value for that machine. That shouldn't be too hard to write. > Okay. Perhaps we should try this hybrid approach: > > Instead of waiting for an event to wake up the soundserver each time > something enters the queue, the soundserver gets an event when something > is in the queue and gets another event when the queue is empty. So, the > soundserver gets the "items in queue" event and starts emptying the queue. > When there are no more items in the queue, it is told to stop emptying the > queue. > > Does this make sense? It would not be as ideal as purely event based, but > should be more accurate/reliable than the current polled_ss. I don't exactly understand. How would the waiting for 16ms work? > > The method of passing the entire song to MCI sounds like the way the best > > way to go (after release 0.3.3). It won't take long for me to write with the > > infrastructure already in the event ss, and looping should also be fine > > since MCI posts a message when it's reached the end of a song. > > That also sounds like a good idea. Using MCI means "cross platform" > (9x/NT4/2k/XP) compatibility. Yes, although fading could be tricky. Cross that bridge later... > > On another note (no pun intended), as previously mentioned, I'm still > > ironing out bugs with the event ss. :) > > ok. Let me know when you think everything is fixed and I'll do some more > testing. I think it's pretty much all fixed. I was going to do some more testing tomorrow on all the games I have (8 of them). The main thing I'm looking at now is whether saved games restore correctly (with the same state) under both types of servers. A day or two ago the wrong instruments were playing but I haven't been able to reproduce that today. Linux testing needs to be done because at this stage I can't test the polled server since ALSA is giving me trouble. I also can't reproduce Chris Kennedy's bug yet. > I've been meaning to ask you if you've used the debug CRT Heap Checking > functions to see if there's any memory corruption lurking. I just read a > book about debugging win32 programs and it seemed like there were some > pretty cool builtin functions for this in the MS C Runtime. If you haven't > done this, I'm definitely giving it a try :) Well there is the function in sci_memory called debug_win32_memory(), but I think I'm a Purify addict now... :) Cheers, Alex.
