The MIDI transfer rate is 31.25Kbps, 10 bits per byte (7 data bits + 1 status/data flag + start and stop bits.) Each event consists of one to three bytes. The number of events per second depends on the song, but Wolf3D's music isn't terribly intensive.
(Just spitballing, but a song at 120bpm = 2b/s, or a probable maximum of 8 notes/second if it's all 16th notes - unlikely - and no more than eleven channels for OPL2 music if it's in rhythm mode. That would be a total of maybe 528 bytes for an unusually high number of note events, plus maybe some controller changes - so we'll say 640 bytes. That's a measly 6400 bits/second.)
So if it was 500 bytes per second that means the code will trigger 500 interrupts per second. Responding to an interrupt is equivalent to a giant pile of cpu instructions plus it thrashes the cache.
The UART in the Amiga is very very primitive with only a 2 byte buffer. So the CPU must laboriously put 1 byte in, then RTI back to the game, execute some game code then respond to an interrupt to load up the next byte to send. All the cpu registers have to keep getting saved and restored each time this happens.
If we had a better UART in AGA, one with a 16-byte buffer then using the serial port would be a breeze.
Playing samples with Paula is no CPU load; mixing audio (which you'd have to do in order to play MIDI music of any complexity along with sound effects) can be quite a lot, depending on the quality.
Oic. You want to use MIDI in order to get a bunch of extra sound channels for free. In that case your original statement stands: it would lighten the cpu load to use the serial port to send MIDI commands to play >4 channels of muzak and let the game just play the sfx on Paula. That would be much less cpu power than software mixing 16 channels or whatever.
Of course if we had an 800 Mhz 060 it wouldn't be a problem to software mix as many channels as we wanted...
