This patch introduces an optional delay to work around the buffer overflow issues seen on first generation MT-32 devices. The length of the delay is calculated based on the size of the sysex payload plus a configurable constant number of milliseconds (based on code from ScummVM which always adds this delay although the constant is only applied for MT-32 devices: http://scummvm.svn.sourceforge.net/viewvc/scummvm?revision=47336&view=revision ).
Rather than introduce the delay when the sysex message is first sent, the time at which it is "safe" to send the next MIDI command is stored, and the delay is before the next MIDI command is processed, allowing any other processing the game may be doing in the meantime to continue (some games may already be introducing a delay to work around this issue and this method avoids introducing a double delay). In my testing I often saw individual delays of < 10 ms introduced, while fixing all problems I was encountering.
I've tested this on Mac OS X 10.6.6 using a real MT-32 rev00 connected via an M-Audio USB interface.
I tested using the following games:
- Sword of the Samurai (worked fine before adding delay)
- Worlds of Ultima: Savage Empire (introduction sometimes worked without delay, but always caused error when starting actual game and "Initializing Roland..." was visible on screen)
- Prince of Persia (failed without delay)
- Prince of Persia 2 (failed without delay)
- Circuit's Edge (good for seeing impact of delay, as sysex payload is sent whenever you enter/exit a location)
I also tested with the samples supplied in this thread: http://vogons.zetafleet.com/viewtopic.php?t=15761