Re: [hatari-devel] MIDI IRQ handling bug

[ Thread Index | Date Index | More Archives ]

This is a multi-part message in MIME format.
Hi Nicolas,

Would you have any objections to me pushing attached MIDI tracing change?

	- Eero

On 12.12.2021 16.09, Eero Tamminen wrote:

On 12.12.2021 15.31, Nicolas Pomarède wrote:
Le 12/12/2021 à 14:23, Eero Tamminen a écrit :
Current Hatari IRQ handling is buggy for MIDI. Midi_UnInit() disables MIDI IRQ, but Midi_Init() does not enable it, only calling Midi_Reset() does, which does not happen on MIDI device change.

(Similarly to handling of RS232, SCC & printer devices, MIDI device change at run-time does not trigger reset.)

I tried calling Midi_Reset() directly from Midi_Init(), but that freezes Hatari at startup (to somewhere in interrupt handling code).

Attached patch seems to work, but I assume all the things done by Midi_Reset() should not be done just on device change.

Could you look into what's the correct fix?

what scenario should I use to see this case and reproduce it ?

Change MIDI device at run-time, e.g. from one that is not present on the system, to a one that is.  In my case, I was doing that right after boot, before starting the Atari MIDI application.

Oddly SMF-Player seemed fairly uneffected, but most MIDI apps (e.g. Sequencer One, Notator, Dr T's KCS) are completely broken by this bug. Synth receives no MIDI events, or they come with huge delays (when one moves mouse?).

I was testing this with the PortMidi fix patch, but same should happen with raw MIDI, as that bug is obvious just by looking at the code:

* Midi_UnInit() disables IRQ set by Midi_Reset() at emulation start, and calling Midi_Init() in Change_CopyChangedParamsToConfiguration() does not re-enable it.

* Only calling Midi_Reset() directly (= my patch), or indirectly (= rebooting emulation) does that.

     - Eero

Mail converted by MHonArc 2.6.19+