Repository navigation
MIDI Input Causes Crash #6266
Description
Checklist
- I have searched the issue tracker and was unable to find an open or closed issue matching what I'm seeing.
- I have verified that the issue is happening in the latest nightly build, or the latest commit, if building from source.
What happened?
MIDI Input crashes 86Box in a variety of VM configurations booting DOS 6.22 and running a variety of MIDI programs that accept MIDI In. Crash occurs when using the standalone MPU-401 emulation with the default address and IRQ, occurs on both Windows and MacOS, and when using different sources of input, from real MIDI controllers and interfaces to virtual ports. Also with both new and old dynarec.
Steps to reproduce: Create a new VM for MS-DOS 6.22, enable MIDI In device and select a MIDI controller, enable "Standalone MPU-401" and use default IRQ and address. Once booted to DOS, load any program that accepts MIDI In, whether a MIDI monitor or sequencer, and play a series of random notes on the controller.
A quick and easy MIDI monitor to use is on the MidiMan MM-401 Floppy Disk floppy image available from Dos Days here: https://www.dosdays.co.uk/media/midi/MidiMan/midiman_mm-401.rar
Insert the disk and run using "viewer 330" at the A: prompt. It can vary in how many notes it takes to reproduce. Sometimes the MIDI input simply ceases without crashing, but more often than not the VM crashes out with a message saying "Exit Code 11"
I'm happy to provide whatever extra information you may need, and happy to provide my specific VM files if that would be helpful.
Configuration file
[MIDI Input Device]
midi_input = 1
realtime = 0
thruchan = 0
clockout = 0
[Roland MPU-IPC-T]
base = 0330
irq = 2
receive_input = 1
[General]
emu_build_num = 7894
force_43 = 1
host_cpu = Apple M4
uuid = bfdca86d-0492-5c61-808f-c604095e9041
vid_renderer = qt_software
[Machine]
cpu_family = celeron_mendocino
cpu_multi = 6
cpu_speed = 400000000
cpu_use_dynarec = 1
fpu_type = internal
machine = p6bat
mem_size = 65536
[Video]
gfxcard = vga
[Input devices]
keyboard_type = keyboard_at
mouse_type = none
[Sound]
midi_in_device = midi_in
mpu401_standalone = 1
[Network]
net_01_link = 0
net_02_link = 0
net_03_link = 0
net_04_link = 0
[Hard disks]
hdd_01_fn = 486dx266.vhd
hdd_01_ide_channel = 0:0
hdd_01_parameters = 63, 16, 1024, 0, ide
hdd_01_speed = ramdisk
hdd_01_vhd_blocksize = 4096
[Floppy and CD-ROM drives]
fdd_01_image_history_01 = MM-401.img
fdd_01_image_history_02 = MM-401.img
fdd_01_type = 35_2hd
fdd_02_type = noneOperating system
MacOS 15.6.1
86Box version
v5.2 build 7894
Build architecture
macOS - Universal (Intel and Apple Silicon)
Build type
- New recompiler
- Debug build
Additional context
No response
Activity
OBattler commentedon Oct 2, 2025
I can't even get it to display anything - 86Box receiving from the same host MIDI device MIDI Player is sending the data to, but nothing comes.
randomtestsubject commentedon Oct 2, 2025
Hi, if you're using the MIDIMan utility, you can use the arrow keys to highlight where it says "View MIDI Data" in the lower right, then press Enter, that should show the realtime MIDI data coming in on the left side.
OBattler commentedon Oct 2, 2025
I got it to work... and it works fine on IRQ 7, but it crashed the emulator on IRQ 2.
randomtestsubject commentedon Oct 2, 2025
I found I was able to avoid an outright crash by switching to IRQ 5 or 7 as well, but when doing so, the MIDI Input would still eventually fail. It wouldn't crash the VM outright, but after a certain amount of time, sometimes several minutes, I would experience missed notes, and eventually the MIDI In would just stop, though the VM would continue as if everything else was normal.
OBattler commentedon Oct 2, 2025
Is your emulated machine running at 100%?
Also, I did get missed notes now (or better, an entire missing channel for some reason).
OBattler commentedon Oct 2, 2025
The problem is that MIDI input is running in its own thread, which doesn't really work well when the emulated PIC is not thread-safe, so there's an IRQ mess.
randomtestsubject commentedon Oct 2, 2025
I tried a variety of different VM configurations trying to troubleshoot the problem, but always at 100%, yes.
OBattler commentedon Oct 2, 2025
Then this is unfortunately a CANTFIX right now - the threading is causing a mess and what's observed with MPU-401 is the milder version of it - the last time I tried MIDI input with the ES1371, for example, I had... very much the same problem but on a worse scale. We're going to be doing an audio rewrite in 6.0, and it's going to involve redoing the passing of MIDI input to the emulated machine as well.
randomtestsubject commentedon Oct 2, 2025
I see, thank you for taking time and checking on this, I'll look forward to a future fix in 6.0. Just out of curiosity, will the upcoming audio rewrite allow users to adjust audio buffers for lower latency?
richardg867 commentedon Oct 2, 2025
The buffer size will be configurable, thank you for the suggestion.
OBattler commentedon Oct 22, 2025
Also, avoid IRQ 2 or 9 for ISA devices on a 686 machine (and, I'd say, any PCI machine, for that matter) - 686 machines all have ACPI, so IRQ 9 (which IRQ 2 is hardware redirected to) goes to ACPI SCI, so the MPU-401 is likely SCI'ing, and I also think PCI machines in general don't bother properly doing the IRQ 2 to 9 redirect, anyway.
randomtestsubject commentedon Oct 22, 2025
So if I'm understanding correctly, there are two separate issues at play, the IRQ 2/9 redirect on ACPI/PCI hardware that results in a crash (which is something that would likely occur on real equivalent hardware) and as such is not really an 86Box problem, and the loss of MIDI input notes (and eventual MIDI input port failure) that is a threading issue related more to 86Box?
I've found that if I bump my VM up to 500mhz (which is just about as high as I can take it on the M4) and use IRQ 7 for the MPU-401 that MIDI in and out is stable with no crashes and no missed notes/input failure, but if I set the clock speed much lower then the missed notes/input failure issue is present. Something about the very high emulated cpu clock speed is able to rise above the issue, so that has become my workaround for now.
OBattler commentedon Oct 22, 2025
Yes, precisely.
And I really need to implement MIDI input queuing like we did for networking.
randomtestsubject commentedon Oct 22, 2025
That's good to know, thank you for confirming that.
On the subject of MIDI, though it's not related to this particular input issue, I posted a feature request in discussions that has some MIDI output timing tests that demonstrate what a huge improvement the recent cpu frame size option makes in reducing output jitter. (#6251) I understand if the feature request isn't viable or of interest, but I thought I'd mention it since it's now capable of tightness that is within plus/minus 1 ms of real hardware. (It's in the section titled 'timing tests'.) It's really remarkable, so I just want to say thank you for adding that.
OBattler commentedon Sep 12, 2026
The loss of MIDI input should be retested now, if that's now fixed, then this can be closed.
OBattler commentedon Sep 12, 2026
OK, it did just freeze.
OBattler commentedon Sep 12, 2026
I did just realize what's actually going on - so if there's not enough space in the queue for all the received bytes, what can't fit, is silently dropped. If the cut-off happens in the middle of a command, the guest program freezes because it remains stuck inside the command.
OBattler commentedon Sep 12, 2026
This should now be fixed - the MIDI input handlers now delay reception until there's enough free space in the queue.
MIDI Input: Delay reception of input until there is enough space in t…