Christoph: > > Even if it did, I believe that the latency generated by our code at every > > note would still make sound under Win32 sound crappy. There's nothing wrong > > with the code (I think!!), but I don't think Win32 scheduling is up to > > handling it. Increasing the priority of the sound thread by only 1 point > > takes so much time away from the main thread, graphics don't even draw. > > Wow.
Well just to expand a little more, we have three threads - the main thread, the SDL graphics thread, and the sound server. I run and test everything on Win NT, which as Matt says, should have a reasonable scheduler. It was very surprising to see how easily I could lock up my system by only increasing the sound server thread's priority to the next level, therefore making it impossible to exit FreeSCI with a non-responsive graphics or console window! We could always play with lowering SDL's thread priority but that probably isn't the way to go... Matt: > Perhaps we should look at what other projects are doing to deal with this? > ScummVM supposedly support MIDI now -- that might be a good reference. > Did you ever look at QueryPerformanceCounter? On my machine, it has > 3,579,545 tickers per second of resolution. > > NT has lightweight threads and preemptive scheduling, and what we're > trying to do has been done before -- it's just a matter of figuring out the > details. Original SCI used hardware interrupts (I think) to achieve > MIDI timing in Windows 3.x -- IReferenceClock (DirectMusic's timer) does > something similar (but with an obviously lower resolution than achieved in > DOS). QueryPerformanceCounter would appear to give somewhat better > resolution than the IReferenceClock interface, so maybe that should be > looked into. Certainly I will look at ScummVM. As for using QueryPerformanceCounter(), that's just another example of why finding solutions has been so frustrating. There are high resolution timers, certainly. QPC() as you mention, GetTickCount(), and IReferenceClock in DirectMusic. But neither support signalling some sort of event object or semaphore to say when a period of time is up. You have to keep checking them. How do you do this without losing resolution? You need some sort of extra thread to tell you. You can't have a thread in a for loop with no sleeps or else no other threads in the process will get scheduled. And if you Sleep(1)? Resolution gone! timeSetEvent()? Resolution gone! Am I missing something simple here? Speaking of timeSetEvent() - have a look at what I'm about to put into CVS (which will solve the linking problem BTW). This has millisecond resolution and should set a lightweight event object every 17ms (as close to 16.6667 as possible). The event sound server waits on this object and then immediately calls do_sound() to play the next waiting MIDI command when the object is signalled. Yet when using this, I only get reasonable sound speed when I drop the timer value from 17 to about 7 or 8. Even then it's not as smooth as the polled server when it's working properly. What does that say about NT scheduling? Or perhaps my event SS code (which I don't _think_ is faulty but could be!) How does it sound on your speed machine, Matt? > Given these facts, it might be wise to take a step back in order to take a > step forward. Some important restructuring was done to the sound subsystem > (that really needed to be done, IMO) to add the possibility of an event > soundserver. I'm not saying we should give up on the event soundserver, > but see what this refactoring and trials can give us in the polled > soundserver. I 100% agree with this. The flow of the polled sound server is difficult to follow (IMHO), and now it can use the shared sound functions in soundserver.c. > I will revisit this with some friends of mine who are hardcore win32 > programmers to see if they have any ideas on how to deal with the event > latency. That would be great Matt, thanks! Christoph: > > So, what I plan to do is essentially abandon the current Win32 sound drivers > > for the event ss, and write a driver that uses DirectMusic. The > > documentation makes it seem pretty easy, and you can convert current MIDI > > data into DMusic format. Saving and restoring sound states is still > > possible. > Fine from my POV (see attached mail). So do we keep your changes or fall > back to the previous implementation (which at least worked on both > platforms)? Merging the best of both worlds would be preferrable, of > course, but the plan of releasing 0.3.3 this year might collide with > this... Definitely keep it since the polled sound server is still used by default on Win32. The UNIX sound driver should now be fixed (is it? I really need to reinstall Linux...). We can always comment out the lines referring to the existence of a Win32 event sound server driver so the command line option won't work. Matt: > You could write a mt32dm driver similar to the mt32gm driver to accomplish > this. I also noticed they seem to discourage the use of MIDI in their > documentation -- which seems pretty bogus since there are Many MIDI > sequencers for win32 that run completely in user space. Like I said, I'll > ask around if anyone has experience with this. Sure, that would be good. I don't know if they discourage the use of MIDI, they just claim that their 'Music' object is more flexible, has more features, and is just better presumably because it's Microsoft. ;-) Anyway, I did look around on the Internet but only found MCI implementations. > Thanks for all your help Alex, it is really appreciated. Sorry for the > frustration you're going through -- I'll try to be more attentive to this > area of FreeSCI from now on. No problems - it's something I preferred to do on my own but now it's pretty much finished except for reverse stereo, the cumulative cue counter, and saving and restoring of games (all only with the new server). Oh, and double checking everything. I'm off to investigate ScummVM! Alex.
