Update: I tried 0.9.1 and the incident no longer happens on my savestate, but it looks like the problem may still occur elsewhere. vBlank is interrupting the audio driver while it's still waiting for a response from $2140 , causing it to miss it entirely and get stuck. I'm not sure what the best fix is but FYI!
Viewing post in Incognity: A rover story comments
I'll join in on the discussion. Khaz is explaining a crash that occurs due to a fault in SNESGSS's communication protocol (Yes, I know what sound driver this game uses. I've known it for many years.): namely, it sends out the last command ID ran to $2140/$F4. However, it then clears the latches some time afterwards, which zeroes out both sides. The SNES can miss the read (with VBLANK being a plausible cause), thus causing an infinite loop. (We were discussing this on the SNES Development Server Discord, actually.)
There are a couple of solutions running through my head per our discussion: the first is to disable vblanks (or other interruptions) entirely while a command is being sent through. The second is to keep track of what vertical scanline you're on (the value to check will be NTSC/PAL dependent, and I see you're targeting NTSC) and wait for vblank if the vertical scanline count is too high, then run the code in question that communicates with the SPC700.
Yeah I know of the issue, sfx_play is not NMI protected because my preferred solution is to have the game fast enough to never drop to 30fps.
It's not quite achieved here, when you're near a boss and with lots of enemies on screen the game may drop to 30fps. Turns out a big, open-world game with 1k entities is a lot for a SNES ;)
Surprisingly I haven't run into the boss yet. I'm just mostly doing exploring and crystal collecting. And yes, I know of the lots of enemies on screen case: surprisingly, I have decided to decline to attack any of them and instead just tank and/or avoid the hits. It also means I find the shields to be practical for this scenario.
If you don't want to deal with a missed VBLANK, then I recommend the scanline check approach to avoid that edge case. Either that, or both the SPC700 and SNES-side programming need to be modified to avoid that entirely.