I have an MT-32 rev00 on Mac OS X connected via an M-Audio USB interface and virtually everything was causing this issue for me. I posted a patch to the tracker a few days ago that introduces a delay based on the size of the sysex data and the standard MIDI baud rate of 31250 (props to ScummVM for that) plus an optional constant delay (for differences in hardware, etc).

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 (sysex or not) is processed. This allows for games that do other things while sending the sysex data or may already be working around this issue. It also minimizes visible slowdown.

Sometimes I have the feeling that the better USB-Midi devices work worse with the MT32. We've had a report for the buffer problem with Exult which neither of us devs with a real MT32 + cheap USB-Midi device can reproduce either on Windows or OS X.
But this doesn't mean you are not right to pursue this 😀

I thought I recognized your name from somewhere. I had submitted an (unrelated) Exult patch a few weeks ago. 😀

I'm pretty sure my USB-MIDI adapter is the cheapest one that doesn't just ignore sysex messages (unlike the fancy one I have which doesn't seem to work with the MT-32 at all). Is there an Exult ticket? I can try and reproduce it when I have some free cycles.

Ah, you've been the clang guy 😀
Yes, a bug report for https://sourceforge.net/tracker/?func=detail& … 0&group_id=2335 and in there I just linked your patch for Dosbox a couple of minutes ago and in the original post a link to the actual bug report in our forum.

Before you get disappointed, as in the forum post, Exult does not playback the intro correctly currently on a real MT32 with a cheapo USB adapter (as my recording on OS X is similar to the one the forum poster made on Windows 7, I presume it's a problem with Exult and not just either OS X or cheap adapter). If you feel like taking this one, be it just by confirming the buffer problem or a nice little patch, you are welcome to and I can assure you we will take a serious lok 😀

Just a quick update; I have made yet another version of my patch which uses some of JCZorkmid's ideas; for details look at the aforementioned SourceForge location. This one removes support for the delayreadystate solution, as it didn't provide any benefits. More importantly, it is based on a new delay calculation and should now compile on Linux and Mac platforms as well. I've actually tested it successfully on a MacBook Air using my Cakewalk UM-1G; no buffer overflows!

Regards,
Ronald

Added to the SVN.

There's a problem with the SVN addition. Wbat exactly is the function remove() in line 203 of midi.cpp supposed to be and where is it defined?

VC++ Express 2010 gives an error along the lines of remove having only one parameter called "FileName", not three, so the function it is thinking of seems to be a function intended to delete files, not remove a character from strings as intended. I tried std::string::remove on a whim, but that doesn't exist. Unfortunately that's about the limit of my C++ abilities. Thanks for your consideration!

Thanks.
Should be fixed.

Fix confirmed.

Thanks for adding this. And thanks to all those who worked on this

Exciting to hear that this is now in the official DOSBox source! Thanks to those who worked on it.

Thanks for adding it into the main tree, Qbix! And thank you Jason, for your input and suggestions! Thanks to all beta-testers!

Thanks very much for getting this into the main tree! And thanks to Ronald for all his help.

Bit late to the party on this, but... Colonel's Bequest by Sierra still has problems on my rev01 (whoops, not rev00) MT-32 even with the SVN patch.

The game makes extensive use of custom instruments and without sufficient sysex delays, my MT-32 misses several instrument customisations: instead falling back on the default instruments (or possibly getting 'half-customised' ones, I can't tell) with often hideous consequences.

The sysex delay in the patch helps - the MT-32 misses fewer instruments when it's enabled - but I had to impose a minimum sysex delay of 40ms to ensure that all instruments sounded as intended. (By contrast, the maximum delay calculated by the sysex patch was about 35ms.)

I'm away from my MT-32 for a week so I can't narrow down yet which sysex messages are getting dropped or cut off, but I'll post more results once I can test it again.

EDIT: Ahh wait, actually I have a rev01 MT-32 (SN 865037), not rev00. And this is a Macbook Air with a no-name USB-to-MIDI adapter cable.

EDIT 2: This was tested by integrating the SVN patch into Boxer 1.0.1 (whose MIDI handling is the same as the release version of DOSBox 0.74.) Without the delay, Colonel's Bequest still had missing/broken instruments at 2000 cycles, with more of them at 3000 and above. With a delay of 40ms, music sounded correct at any CPU speed.

Boxer 1.0.2 includes a version of the patch with a quick hack to set the minimum delay to 40ms when delaysysex is enabled. (This is obviously not a proper solution, but didn't negatively affect any of the games I tried - apart from considerably slowing load times.)

Thanks Vigil, I'll see if I can reproduce it at home. I've noticed that NFL Football also seems to require an additional 2 ms. delay, maybe the calculated delay is a tiny bit too short.

Out of curiosity, how did you arrive at the constants used in the current patch's delay calculation ((payload * 1.25) + 2)? I didn't catch an explanation of those in the rest of the thread.

Mostly trial and error, see http://sourceforge.net/tracker/?func=detail&a … 551&atid=467234

If you are having problems with thr rev01, then you really should make sure that the USB adapter is not the weak link. There have been reports of some that don't work correctly. I don't have that game but maybe we can work something out. I'm on a mac, too with a rev 00 mt32.

Vigil, reading your post it sounds like you aren't using the actual code that was accepted into DOSBox, but one of rcblanke's older patches... is this correct? Can you test the actual code that's in the latest DOSBox tree (no patches) and see what you get?

I will note that most of the other programs that work around this issue do so using:

1((midi.sysex.used+2)*1000/3125) + 40

Which is enforcing the defined MIDI baud rate (plus 40ms, which is due to a specific MT-32 bug), rather than the code that eventually made it into DOSBox:

1(Bitu)(((float)(midi.sysex.used) * 1.25f) * 1000.0f / 3125.0f) + 2;

But rcblanke had better luck with the latter.

Also, any time you get any error on your MT-32 I recommend you power cycle it before doing any more testing, because it will continue to get errors even when it should not otherwise.

Dominus: the adapter certainly could be introducing problems of its own, e.g. it could be dropping larger MIDI messages that are coming down the pipe too quickly. I would need either another connector or another MIDI device to rule it out altogether, but you could try to replicate the Colonel's Bequest instrument problems (or buffer overflows) on your rev00. Are the rev01's not known to have any lingering MIDI-processing limitations of their own?

JCZorkmid: I ported changesets 3687 and 3688 from DOSBox SVN: http://dosbox.svn.sourceforge.net/viewvc/dosb … 688&view=markup. I oversimplified the constants in my post, the actual code being used is (Bitu)(((float)(midi.sysex.used) * 1.25f) * 1000.0f / 3125.0f) + 2 as it is in the accepted patch.

(I also make sure to always power-cycle the MT-32 between launches of a game when testing.)