> win32p is a polled soundserver --it constantly polls the event/data queue > waiting for a MIDI event to show up. This ends up being CPU intensive and > can starve the main thread, so when the queue is empty, we Sleep for 1ms. > This is a small problem at MIDI requires a slightly more accurate timer. > That's why a few notes will not be times properly as various times. > > win32e is event based -- when something is put into the queues, an event > it sent to the soundserver telling it to get the event/data from the > queues and deal with it. Alex and I still haven't figured out *why* the > win32e server plays slowly -- I suspect we're missing something.
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). > The directdraw driver currently has color problems, which could probably > be easily resolved by someone who knew what they were doing. I tried > looking at this before and just didn't understand what was going on in > some places. What needs to happen is to print out the color values and > compare with SDL to see where the mask goes wrong. > > For the moment, I would just use the SDL driver. 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. Alex.
