search

joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.83k stars 383 forks source link

MIDI broken in 0.83.15 on M1 Mac #2635

Open Skaggynuts opened 3 years ago

Skaggynuts commented 3 years ago

0.83.15 seems to ignore any MIDI configuration and defaults to coreaudio. I had been using Munt for MT-32 emulation as I couldn't get the built-in emulation to work, but now it won't play though Munt and just uses core audio, same results if I try and use fluidsynth.

joncampbell123 commented 3 years ago

It's supposed to try MT-32 first, then CoreAudio. I had also fixed a bug where no MIDI out was audible on my macbook because the CoreMIDI API does not report any MIDI destinations.

joncampbell123 commented 3 years ago

Looking at midi.cpp, MT-32 emulation is listed first. The MidiHandler constructor adds the instance to the head of the handler list, which means MT-32 is tried last.

To get MT-32 you will need to add "mididevice=mt32" to your dosbox.conf.

It is probably best for DOSBox-X to try CoreAudio first before MT-32 by default.

It probably worked in the past because of some issues with MIDI support and Big Sur.

On my Macbook, CoreAudio MIDI failed because something to do with SoundFonts. The code apparently assumed that if it couldn't load a SoundFont with CoreAudio that it should completely give up (something about a crash on OS X 10.5 long ago?). My fix was to let it continue with the system default instead.

Second, is CoreMIDI, which my system used because of the CoreAudio issue mentioned above. Apparently Big Sur does not list any MIDI destinations, but CoreMIDI assumed device 0 anyway, which is why nothing could be heard. That was fixed, so that CoreMIDI returns an error instead if Big Sur says there are no MIDI destinations.

rglidden commented 3 years ago

As described in #2056 it looks like MT-32 emulation isn't even compiled into the M1 Mac version though, so adding "mididevice=mt32" has no effect.

joncampbell123 commented 3 years ago

@rglidden Looking at config.h on the M1 Macbook... and you're right. C_MT32 isn't defined.

Furthermore configure.ac won't define C_MT32 unless the host processor is x86_64 or i686.

Modifying configure.ac to define C_MT32 for "arm64" and doing a compile test now.

joncampbell123 commented 3 years ago

@rglidden Apparently the MT-32 emulation compiles and runs just fine on M1 Macbooks, so it is enabled starting with the latest commit.