Closed holly-hacker closed 5 years ago
Thanks for the report!
@noname22 do you have any idea on how this WinMMMidiInput.HandleLongData()
could fail like this? I will try by myself once I got a working Windows development setup too.
What I have figured out so far:
I want to mention that I didn't have this when I was using NAudio, so comparing to it may be useful.
I wouldn't be surprised if we get a MidiInMessage.Close before that message (which we currently ignore).
See here.
If that's the case we should ignore any messages after close.
Thanks, but it does not seem to be sent. I tried adding case MidiInMessage.Close
in HandleMidiInProc
but it does not happen (at least before the crashy message above). Looks like the message size (buffer.Header.BytesRecorded
) is 0.
Thanks, but it does not seem to be sent. I tried adding
case MidiInMessage.Close
inHandleMidiInProc
but it does not happen (at least before the crashy message above). Looks like the message size (buffer.Header.BytesRecorded
) is 0.
Ah, crap :(
Is it possible to just skip any zero byte messages?
After all there was no any decent solution, so I just added a workaround (skip it) code at 6b197af. I will be pushed to nuget soon.
I run
MidiAccessManager.Default.Inputs.ToList()
every 500ms, and it crashes with the following stacktrace when a MIDI device gets removed:Input from my device works fine, and on Linux I don't have this issue. You can see my usage here.