moved to development.
could the cpu cycles be an issue ? DOSBox mpu is always ready to recieve. Although it is a wild guess.

Can you please test it with te build which I uploaded in this thread?
does dosbox support MIDI IN yet?

Could also be related to buffer overflow problem when games quickly sends lots of sysex data. Try to reduce CPU clocks (to a very low value, like 100,200 or 500) for game startup and ingame loading. AFAIK(R), unfortunately win32 or alsa seq API's don't provide hooks which could help with throttling in this case, or at least I couldn't find it. From the Dosbox point of view, to throttle we'd need just to set one status bit which is returned in a port 0x331 read.

I have tested both at extremely low cycles and with the compiled build, but the results are the same. I didn't think that speed would be the issue as my Win 9x box runs with a Pentium II 450MHz and it worked there without any sound flaws in the method I describe above.

Throttling issue is not related to CPU speed of a real machine, but is related to dosbox cycles (because real MPU401 will set a status bit if it is not ready to receive more data so the problem doesn't exist).

Did you also try with mpu401=uart? (if this setting works at all with Sierra games...) as it should not filter any data in the MPU401 emulation part.
If that works, but produces same problems, cause could be with dosbox midi-out buffer if sent data isn't valid MIDI (or even if device distinguishes e.g. midi running status-a shortened form of message- from the full one, as it is expanded). In that case real mpu401 device could be more resilient to errors than dosbox (here I don't believe that such data could even pass through win32 midi interfaces, but is probably doable with ALSA rawmidi).