Fixes https://github.com/open-goal/jak-project/issues/2635 by zeroing
out the volume of the VAG command on the first chunk upload. This isn't
a "true" fix because I'm only addressing the symptom instead of the
actual problem.
But this did allow me to complete Mountain Temple without a single chirp
of static from the `mtn-step-plat-rocks` explosion sounds. They were
completely silent until I hit their buttons. All other sounds in the
game, to my untrained ears, sounded unaffected.
As an additional concern, I clear the IOP threads' `waitType` whenever
their `state` is set to Ready. This didn't seem to affect the sound bug,
but it seemed to be "the right thing to do." Will happily remove this
from the PR if it's deemed unnecessary, extraneous, or ought to be
addressed separately.
This is not a fix, but it temporarily works around the potential crash
discussed here https://github.com/open-goal/jak-project/issues/2988
As long as this doesn't impact other things, this feels like a good
interim fix, as having a broken cutscene is better than a fatal crash
and it might be some time before this is properly identified and fixed.
Normally, when they allocate a VagCmd, they do a bunch of stuff to clear
all the status bits and reset things
in particular the InitVAGCmd function does a lot
but for the stereo command, they do a lot less:
Which means that the new_stereo_command can just have random status bits
left over from whatever the last user had.
we seem to end up in a state where byte21 is set, and this causes
everything else to be wrong and off-by-one dma transfer. My guess is
that the original game avoided this bug due to lucky timing that I don't
understand.
I think the fix of just clearing byte21 is ok because there's no way
that the old value of the byte is useful after the command is
repurposed.
massimilianodelliubaldini