On Sun, 16 Dec 2001, Alexander R Angas wrote: > 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. 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? > Speaking of that, I forgot to mention in my last CVS commit that HAVE_DDRAW > is no longer defined in the Release builds since the colour problems don't > make it 'release' quality. Fine by me -- I removed it once before and someone said I should put it back so as to encourage someone to fix it. (Guess that didn't work after 6 months, so.. ) BTW, is a Purify configuration in the workspace necessary? Why not just lump SATISFY_PURIFY in with the Debug build? -- http://www.clock.org/~matt
