|Re: [hatari-devel] MIDI IRQ handling bug|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
This is a multi-part message in MIME format.
Would you have any objections to me pushing attached MIDI tracing change?
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
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.