Emulator

Does the md5 of your iso match the one on redump.org?

Yes, at least it does after I decompressed it, can still reproduce the issue either way. I have found a workaround by disabling the frame limiter. 3.0-594 still works with the limiter on or off.

Does the game also restart in Single Core mode?

This is not happening for me, I made it to the boss and beyond.

http://i.imgur.com/2i7cL.jpg

3.0-700 - 64-Bit

Asus Laptop: K53TA
OS: Windows 7 Home Premium, 64-Bit - SP1
CPU: AMD Llano A6-3400M, Quad-Core, 2.4GHz (Overclocked)
GPU: AMD Radeon HD6650M, 1GB GDDR3 (HD6720G2)
RAM: 4GB DDR3-1333

Hmm, just tried the game again, and it randomly rebooted somewhere other than the boss fight. Looks like a legit issue.

Yes still present in single core mode.

The game works fine here.

3.0-710 - 64-Bit

OS: Windows 7 Home Premium, 64-Bit - SP1
CPU: AMD Athlon II X2 240, Dual-Core, 2.8GHz
GPU: AMD Radeon HD4670 OC, 1GB GDDR3
RAM: 4GB DDR2-800

It's random. You'd have to play the game through the first level several times to see if it happens.

In 3.0-594, did you have DTK music enabled or disabled? It should be enabled for this test.

Yes DTK music was enabled.

Also it seems disabling the frame limiter and letting vsync keep the game speed in check only reduces the reboots(3.0-600+), Ive still had a few completly random ones. When this setting is on auto its always been the 2 spots mentioned in the issue report on my machines.

In the audio settings, do you have 48000hz or 32000hz selected? It should be 48000hz. Please also try the game with "No audio output". Sorry for not bunching up the questions in one shot. I am writing them as I think of them.

No problem. Its been set to 48000hz. Tried no audio 3 times now and It seems to make things reboot more quickly (first wave of medium sized ships) switched back to xaudio2 and reboot at the boss fight again. Dsound also gets to the boss fight. LLE recompiler didnt seem to make a difference nor did LLE interp. All of these results are with the frame limit set to auto because the reboot is more consistant this way. Im pretty sure the linux box was on alsa 48000hz but I dont have access to it right now. It was a dvr i built for my parents. Just for the sake of testing I tried 3.0-594 with no audio output, no reboot.

32000hz no reboot after running through the first level twice. Switched back to 48000hz reboot on first boss... I'll try this some more tomorrow if I have time.

Today 32000hz reboots just like 48000hz... GAH randomness!

I took a look at this issue and it is resetting because the music has gone out of sync with the game. I can get it to consistently reset if I set the framelimiter to 40fps (66% speed). The game does not reset if it is running at 100% speed.

Technically the game has detected that an AISInterrupt occurred when it is not expecting one. It then resets.

The reason why this occurs is because Dolphin plays music back in real time. Notice how the music does not slow down when the game is running slower than normal. Old versions of Dolphin did not reset because the AISInterrupt timing was not accurate.

To fix this issue, we either have to match the music to the game speed (would cause the music to lag and sound like crap), we get the game run at 100% speed (needs a faster PC) or get the AISInterrupt to occur when the game expects it to in some other way while maintaining accuracy. Currently, I don't have any ideas on the latter. The first option is the "most accurate to the hardware" option.

For making the music match the game speed, can it just do the typical thing that HLE does and create more interim samples (e.g. Zelda ucode [I think])? Or does it inevitably sound like crap if you do that because it's recorded and not MIDI? </pauls_crackpot_theories>

As a demonstration of "matching the music to the game speed," I made a timing change to the "No Audio Output" backend which fixes this issue.

paul, time-stretching the audio is possible, but not 100% fool-proof as the audio back-end would have to inquire the number of frames/cpu cycles that have been executed in the last X time period and using that as a number to gauge the number of frames/cpu cycles in the next X time period.

I guess if the fix is to run the game full speed, (as intended) then there is no issue.

You'd think this game should be one of the easier games to run, but some spots on the first level are pretty brutal. Going from 120% to 50% because a few extra ships are on the screen is not normal for a small 2D/3D shooter like this.

Well its at least nice to know the cause of the issue and to have a work around, thanks skid. It seems odd there aren't more issues like this for other games.

"Well its at least nice to know the cause of the issue and to have a work around, thanks skid. It seems odd there aren't more issues like this for other games."
Fzero also suffers from sudden reboots, this might be the case.

If it is the same issue the "no audio output" backend should fix it in current master builds. I'll see about testing it this weekend.

Haven't had much time to look into this and so far I also haven't had any success reproducing a reboot in fzero on newer builds, just a few 0 fps lockups. I do remember this game rebooting but it seems like it was determined to be a duel core problem. Is there a certain part of the game where they are more frequent? Did the reboots happen before 3.0-600?

Checked into f-zero a little more, can still reproduce reboots with no audio output but cannot in single core mode. Looks like a different issue.