> > This is true. You may also find that the event sound server plays things > > more 'correctly' than the polled sound server (timing not withstanding) >and > > vice versa. You really need a very fast machine to run the event sound > > server with the correct timing (I'm guessing the top of the range >Pentium > > 4/3 / Athlon available now). > >Okay, just spent a bit revisiting this. > >First thing, I've changed the win32 MCI midiout driver to use >midiOutShortMsg which has less overhead than the previously used >midioutLongMsg. I barely noticed a difference, but Quantify (a profiling >tool) says it does take up less execution time now.
There are some places where there is a definite tempo increase. (Like about a 25% tempo increase in some instances) Other places sound pretty close to the way they were before (slower tempo when using win32e). BTW - I never said this, but I am running a Pentium III 700mhz. >Second thing, the largest consumer of function time in the win32e >soundserver are malloc and free calls in the sound_win32e_get_command, >sci0_event_ss functions. Perhaps event_temp could be allocated/freed once >instead of thousands of times during my 45 second run? Hehehe. If it is possible to do that, it sounds like it should be pretty helpful. Sounds like me trying to clean up my faster than a speeding slug OpenGL ray-tracer. :) - Chris P.S. Still get "crash on Midi" when using win32p or sdl for the sound_server. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
