Bad SysEx can cause mt32-pi to hang

[vesami]

I'm using pi-midi and cheap midi adapter. The problem is as follows: when starting a game I need to restart the Pi to get sound out of it.
Here's a demonstration: https://www.youtube.com/watch?v=gb6bEEK0EP8
I start the game at 00:12, and the game starts to send signal almost immediately (don't mind the label IN, it's wrong).
Then at 00:23 I unplug the pimidi's power and plug it back at 00:26. After restarting the sounds are played just fine and display updates. I tested with the gpio_thru option and the data is moving around even if there is no sound and the green led on Pi is not flashing.

Any ideas where the problem could be?

[dwhinham]

Hi there!

These cables are known to corrupt SysEx data [1, 2, 3], and it looks like mt32-pi is getting confused/stuck because of garbage SysEx data being received.

Most MT-32 games send SysEx data to setup instrument mappings and parameters before the music begins, and if this is not received, the music will sound wrong.

My guess is that the start of the data is received, which mt32-pi notices, and then all subsequent data is then treated as SysEx as it never receives the trailing F7 byte, leaving it stuck and not playing any notes. The green light will only flash on the Pi when a note on/off or control message is successfully received, and not when it's reading in SysEx.

I can improve this behaviour so that when a limit is reached it throws away the garbage, displays a warning, and goes back to the usual state of expecting notes, but this does not fix your cable, and the music will still sound incorrect.

The real fix is to invest in a quality MIDI cable like the ones we recommend.

There is one thing you can try though - you didn't mention your source configuration. Is it Windows and ScummVM?

Linux has some USB MIDI driver workarounds [1, 2] to try and sidestep problems with these cheap cables.

Can you try a Linux machine as a source with the USB cable?

[vesami]

Thanks, I was expecting that the cheap usb midi cable would be the reason. I'm using Windows, Dosbox and games from gog.com.
I do have access to Linux, I'll test it later.

[dwhinham]

Great, yes DOSBox on Linux would be a good test.

I've looked into to proper way to handle SysEx problems from the MIDI specification, so whilst the cable is probably at fault, mt32-pi does definitely need to be able to recover from data corruption and not get stuck, so I'll work on this too.

Thanks for your report!

[vesami]

Works perfecly on a Linux machine :) Just had to use pmidi -l to get the device (20:0) and add it to the dosbox configuration.

Anyway I ordered the recommended Roland cable so I can use it in Windows, too.

Thanks a lot.

[dwhinham]

Excellent! Thanks for testing this.

This is valuable information, I'm not sure if many people realise these cables may be salvageable if used on Linux, so I think I'll add this to the README or a wiki page.

I'll create a test build for you to try soon that should fix the getting stuck issue. 🙂

[dwhinham]

Hi there!

I've done a pretty big rewrite of the MIDI parser and it should handle faulty SysEx better now.

Could you try your cheap cable under Windows with this build?
https://github.com/dwhinham/mt32-pi/actions/runs/252614148

The instruments will sound strange as the SysEx is of course still going to be broken because of the flaws in the cable's firmware, but mt32-pi should at least keep going and not hang up. You should get some warnings on the LCD too.

It'd be great if you could confirm things are still good on Linux with this version too.

Thanks!

[vesami]

Yes, it's working somehow now with the cheap cable and Windows 10:
https://youtu.be/vs5QXcz6WVs

And here's Linux, seems to work just fine:
https://youtu.be/7DF7tPJQqw4

[dwhinham]

Excellent, thankyou for making the videos and testing this! It's very interesting to know that the cheap cables can be used more reliably with Linux.

Hopefully the new MIDI parser will still work reliably with the "good" cables too - it works for my M-AUDIO USB Uno but I'd like to know how it works with the Roland because that interface uses Running Status (for higher efficiency), and I don't have one of those for testing.