possibly a weak onboard CPU that can't keep up with fast MIDI messages. the 80C32 on that board is a fully 8-bit design, while the roland and yamaha modules from the time used 16-bit internal/8-bit external designs. the 80C32 is clocked higher at 33 mhz though...

besides, the board with the issue has a much earlier dream chipset anyway. try to find out whether there is another board with that chipset but a different microcontroller.

auron wrote on Today, 14:43:

possibly a weak onboard CPU that can't keep up with fast MIDI messages. the 80C32 on that board is a fully 8-bit design, while the roland and yamaha modules from the time used 16-bit internal/8-bit external designs. the 80C32 is clocked higher at 33 mhz though...

besides, the board with the issue has a much earlier dream chipset anyway. try to find out whether there is another board with that chipset but a different microcontroller.

Mh, if that's by design, it would be real bad.
I'll try to find someone who has the same daughterboard and find out if theirs sounds as bad as mine then.
I noticed that unlike the SOWT-24, it has not 32 but 24 voice polyphony, but I doubt any of the MIDIs were using more than 24 voices simultaneously.

I tried recording this with Audacity 1.3 Beta on W98SE, but whatever I record is real choppy (also the audio graph updates really choppy). At first I thought it was because the system was relatively slow (166 MHz, 64 MB RAM), but even after upgrading it to a K6-2+ 550 and 256 MB SDR-100 it still has trouble recording smoothly. Will have to fix that first (or rather find a less demanding recording tool) so I can show the actual issue.

that audacity is from 2011, probably not written for a K6 that doesn't even have SSE. you can't record it on a newer computer?

i have found the SCW001/2 on wavetable.nl, has the SAM9203 and 80C32 like yours, but uses different a crystal ROM and lacks the SAM8905B effects processor. doesn't seem to be doing too bad in the recordings, but you can tell at the end of grabbag it's slightly off beat. it's subtle though.

anecdotally, i have heard that the 10mhz 68k that was on a lot of MIDI hardware is also not the best for heavy MIDI files, like what you would get in doom or duke3d user content. it's hard to say for sure if timing issues are coming from the tone generator or the onboard MCU, but i think one good benchmark is to use MIDI thru, on a slow MCU it should wreck performance. only applies to external modules and not daughterboards obviously.

The "user content" can be made in a way that would only be playable on a softsynth by having so many MIDI messages that would saturate the 3125 bytes/second bandwidth of a MIDI UART link. I have plenty of MIDI files that I cannot play over a single piece of hardware over MIDI just because of this issue. They choke and hiccup and stutter and at the same time make the machine very unresponsive as the MIDI driver is waiting for bytes to send because FIFO is full too...

yeah, i'm aware of files like that, but the difference is they choke on any MIDI hardware because as you say the bottleneck is the MIDI link itself. the issue here, at least if i'm understanding OP correctly, are much more subtle timing issues that just happen on certain MIDI hardware.

3125 bytes/s should be a small number to read even for a MCU design from 1980, but at the very least it's twice than that from having send the MIDI stream to the tone generator, and the MCU in these devices is performing other tasks at the same time. the H8 in the SC-55 etc. is much newer and probably more capable, which is why you don't see these issues as much in those devices. alternative explanations could be wave memory read bandwidth limitations on the tone generator or even too slow attack on certain patches...