Emulator

Haven't been able to reproduce this one. Try changing the DSP back-end, frequency or maybe the audio driver?

Changing the backends doesn't worked, and when using XAudio2 the audio playtime extends, but the issue still occurring after some time (about 3 or 5 minutes). My driver is the default Windows 7 audio driver, using the audio driver of manufacturer also doesn't have any effect and the issue still occurring...

I am having the same problem here, The game starts normally but after some seconds, the audio just hangs and keep looping the last sound effect... i'm using the 3.0-191 x64 version of Dolphin.

My specs are: Windows 7 Ultimate SP1 x64 / Pentium Dual Core e5200 O.C @3.33ghz / 2x 2gb ddr2 O.C @890mhz kingston / Geforce 8600GT 512mb O.C @608/378/1350

I'm using the same Dolphin version (3.0-191) and the sound seems perfect (but I'm on XP 32-bit).

if audio works fine with dsp lle, then you have your problem.

HLE is not fully implemented, may never be and skids lle is pro.

#danialho...@gmail.com: HLE audio worked fine with this game in 3.0-179 and older, this is a new issue occuring post 3.0-183.

Also, the same issue are occurring with Zelda: Four Swords Adventures (G4SE01), that worked with HLE audio too

And about Super Mario Sunshine, I found out that watching the intro video until the end make the audio working for more time. If after this the audio starts to keep repeating the last played SFX, saving state and loading it back make the audio working again for some time until the issue occur again (this workaround only work if you have watched the intro video until the end and the audio starts repeating the last SFX instead of getting garbled)...

Finally I could reproduce this, but your issue was somewhat "poorly" written, I mean you wrote you had the audio problem after booting the game, not after skipping the intro and starting a new game.
Yes I can confirm that if you skip the intro you get messed up sound in-game (or even in the menu if you skip it at the very beginning) and that Dolphin 3.0-179 (Revision 8d9061ac39ee) doesn't have this problem.

Sorry for the bad english, and this issue are occurring also with Zelda: Four Swords Adventures (G4SE01...

In Four Swords, the intro video doesn't start (you need to press A to skip the black screen), then the audio works fine, but when you get ingame, the audio messes up after some time.

I have to partially rectify what I've written, because on my system the problem seems to be random (tried a lot of times and it happened let's say 2 times of 8 tries) and that r3.0-179 is affected as well because I had 1 time the sound looping in this revision as well.

For me in 3.0-183 or newer this always occur for me (only the amount of time needed for sound getting messed up vary), and I've finished Super Mario Sunshine with about 80 shines in 3.0-179 with this issues occurring 5 times only...

Well, this issue is very "subdol", the problem is that music and sound effects disappear after a while (a long while)...to test it I let the game open on the taskbar and waited till music&sound stopped.
From my tests I can say that Dolphin 3.0 doesn't have this problem, while 3.0-179 is affected, so I don't think that r 3.0.183 is responsible, it must have been some other revision but I do think that it will be almost impossible to track it down.

P.S. HLE sound got definitely some regression after 3.0 release, because with other games I got sometimes random repeating of the last sound effect played even if those games weren't affected by this bug (happened recently in Terminator 3 and Killer7, but it was not someting constantly happening at the same point like it is in Michael Jackson Experience)

Yes, but in 3.0-179 the HLE audio are more stable than in 3.0-183 and newer, in 3.0-179 you need more than about 60 minutes of gameplay to make this issue appear, on 3.0-183 and newer I'm getting this issue generally in the first 5 minutes of gameplay...

Also, I think that is something related to Super Mario Sunshine UCode, games that uses or that are based on it are getting issues too (until now, I can only confirm Zelda Four Swords, the UCode of this game seems to be the same or at least based on SMS)

Sorry, but on my system I can't confirm your HLE tesis: just tried SMS with 3.0-67 and after more than 30 minutes sound was still ok, then tried 3.0-179 and after less than 5 minutes sound got corrupted (for corrupted I mean that it doesn't play anymore music and sound but only what it seems a continuous note while the rest of game is still running perfectly).

Weird issues, probably my PC fault, now, even on 3.0 stable I'm getting corrupted sound after 2 or 3 minutes... I'll try to update my audio drivers (or even format my PC) and try again to confirm this...

Ok, after many hours of testing I finally got it: must have been the GC-mic branch merge, because on my system (WinXP 32-bit, Sblaster X-fi)last HLE sound stable Dolphin version with SMS is Revision 18d9a275e70c (r3.0-161); starting from Revision 3fc5d8d7cf90 (r3.0-176) music and sound effects usually stop after almost 5 minutes of game-play (you still hear the wind in the background but music and sound effects are completely gone).
So the problem started with r3.0-176 and not r3.0-183.

I'll take a look after I finish reinstalling my audio drivers...

Sooo, after formatting my PC and reinstalling my audio drivers, I can confirm Hatamuro's test, the problem started on 3.0-176 (GC-Mic merge), from my tests it's currently occurring with Super Mario Sunshine (GMSE01) and Zelda: Four Swords Adventures (G4SE01)...

In r201, super mario sunshine SFX sound faces some problems after about 5 minute from playing, and the audio starts to keep repeating the last played SFX..

I think that Super Mario Sunshine is not the only game affected, I experienced some HLE regressions in other games randomly loosing sound or keeping repeating the last sound effect(those games weren't previously affected by this problem).

not only Mario Sunshine, Zelda Four Swords too...

If it can be helpful, I found out that only Dual Core mode is affected (with single core mode enabled SMS sound doesn't stop or loop).

Issue 5074 has been merged into this issue.

The issue is caused by Ln 296 of PowerPC.cpp:
ExpansionInterface::UpdateInterrupts();

This doesn't seem to be thread safe.
Uncommenting it solves the issue, but probably creates problems for GC-Mic.

confirm this issue
iya@hushmail.com, thanks for solution

Has someone able to test if the fix in Comment 26 cause issues with GC-Mic emulation? I got a custom build with the line 296 of PowerPC.cpp uncommented and it fixed the issue with Super Mario Sunshine (and probably with any other game based on Zelda UCode -- seems the same used in SMS), but I don't own any game that use the GC-Mic to test if this fix broke it functionality...

Give a link of your build and we'll try to find out...

Just to report that Zelda Wind Waker (GZLE01) is affected as well

Would you please retest if this issue still occurs with the latest build 3.0-690?

Tried r692 with Super Mario Sunshine and the issue seems to be fixed...I also tried Metroid Prime and I cannot hear anymore the "garbled/crackled" sound when you repeatly shoot with the cannon (but I don't think there was an issue for that).

Really fixed... No issues on Zelda Four Swords and Super Mario Sunshine

I'm using 3.0-735-dirty Windows 64bit build, and this issue appears to be back.
My symptoms: Wind Waker's sound getting stuck after a few gameplay (1-10mins). Even worst, this leads to a game stuck when a chest is opened while the audio is stuck.
Apparently solved when Dual Core is not enabled, though I didn't test this as a fix extensively, but it seems to coincides with this error.

The issue is still fixed in Super Mario Sunshine using r 3.0-746, so maybe that Wind Waker problem could be eventually related to issue 5563

Also having the Problem in SMS in r 3.0776 Win 64 build

This issue is happening for me with the MOST RECENT build. If it was really fixed before, it seems to be broken again...

I am using 3.5- 1722 and I have this issue. It never happened until I got to Ricco Harbor.

64 bit build btw

Use LLE to fix this. HLE still sucks for a handful of games, this one included.

We know that HLE sucks for games with Zelda UCode (like SMS), but this issue specifically never occurred before the merge of GC-Mic branch. It was fixed in rb0d271db3c7e but broke again in some recent revision.

I can confirm that this issue returned in the latest development version, but I'm lacking time to track the exact revision that broke the fix made in rb0d271db3c7e

Issue still here with dolphin-master-4.0-3471-x64.
Perhaps it should be changed to "Open"?

Regards.

Nope, we have issues for Zelda HLE stuff. Zelda HLE is broken, this particular problem though, is fixed.

Thanks for clarifying. You mean Zelda UCode games?

I too am experiencing the same problems described here, with the latest development release (4.0-3830). While I see there is a more general issue open for "Zelda HLE stuff", I have to wonder if this still has something to do with the very specific problem mentioned above in https://code.google.com/p/dolphin-emu/issues/detail?id=4940#c26 where the gc-mic branch merge introduced a non-thread-safe call to ExpansionInterface::UpdateInterrupts() in PowerPC.cpp's CheckExceptions() function. That call is still there. I tried commenting this out (which worked for others back in 2012), but it seems Dolphin now relies on this call as it now results in a hang.

I'd like to understand better how this worked before the gc-mic merge, but that was in the Google Code days. Are revisions from before the github move lost at this point, or can earlier revs still be browsed somewhere? I'm an experienced C++ game developer, and I'd like to help.

Just, it's Zelda HLE, it has serious problems, there is no quick fix. Sorry I can't explain it better for you.

Revisions from before the github move can be viewed here: http://code.google.com/p/dolphin-emu/source/list

Hey, I think I've had a bit of a breakthrough here.

I made the UpdateInterrupts() function in Core/HW/EXI.cpp thread safe, by following the same pattern used for ChangeDevice in that same file. So, up top I have:

static int updateInterrupts;

Then, in Init(), I call:

updateInterrupts = CoreTiming::RegisterEvent("EXIUpdateInterrupts", UpdateInterruptsCallback);

Then, the old UpdateInterrupts function gets replaced with:

void UpdateInterrupts()
{
CoreTiming::ScheduleEvent_Threadsafe(0, updateInterrupts, 0);
}

void UpdateInterruptsCallback(u64 userdata, int cyclesLate)
{
// Interrupts are mapped a bit strangely:
// Channel 0 Device 0 generates interrupt on channel 0
// Channel 0 Device 2 generates interrupt on channel 2
// Channel 1 Device 0 generates interrupt on channel 1
g_Channels[2]->SetEXIINT(g_Channels[0]->GetDevice(4)->IsInterruptSet());

bool causeInt = false;
for (auto& channel : g_Channels)
    causeInt |= channel->IsCausingInterrupt();

ProcessorInterface::SetInterrupt(ProcessorInterface::INT_CAUSE_EXI, causeInt);

}

Finally, in EXI.h I add a prototype for it:

void UpdateInterruptsCallback(u64 userdata, int cyclesLate);

For me, this lets me run Super Mario Sunshine with rock-solid audio, with HLE and dual core on. I had two systems that SMS would reliably lose audio on previously - a AMD A4 3400 2.6GHz and a Pentium E5700 3GHz system - and it runs well on both now.

I'm a complete noob with Dolphin development so I'd like to test this for awhile and get feedback on whether this could have bad side effects before considering contributing the change back.

Have you tested the GC microphone feature with this change?

Hrm. I can't seem to get the mic test to work in Mario Party 7 with or without this change. I've got a working mic as my default device in Windows, and set it to slot B in the GameCube configuration. I'll have to investigate further.

Ah, I had the mic button mapped to gamepad 1 instead of 2. The in-game microphone seems to be getting a signal in the mic test of Mario Party 7 with this change in place. Should probably make sure a minigame actually works though.

The problem will be proving that this behavior is more accurate, or at least not less accurate.

It's obvious that something weird is happening under slowdown; both of those computers would obviously struggle to run it decently even with all the speedups.

With all the other recent speedups, SMS actually runs pretty well on these systems with this change. 30 FPS / 60 VPS pretty solidly.

To me, having audio is more accurate than not having audio and having threads stomping on each other instead :) But I agree it is very possible this change could have unintended side effects. It's up to the maintainers I guess if you want this or not, or if you have advice on how I'd go about proving accuracy.

In my opinion: If you found a solution that fixes the issue and there are no side effects... then what's the point in /not/ fixing it? Obviously, if we can have the higher stability, we'd want it, right?

I don't know much about the threading code (or any of the code ;)) but I don't think this could cause any serious issues, and if it did I'm thinking someone would catch it during the review process.

frank, would you please create a PR with the change at https://github.com/dolphin-emu/dolphin/pulls and we will take a closer look?

PR #1415 created https://github.com/dolphin-emu/dolphin/pull/1415. This is my first-ever github contribution so apologies in advance if I screwed something up :/

Been testing this change some more today and it still seems solid so far.

The change in PR #1415 caused DKCR to slow down greatly. I have made a small tweak to fix that. Would someone please test SMS against the fix for me?

https://github.com/dolphin-emu/dolphin/pull/1479

Please test the fix by compiling the patch:
https://github.com/dolphin-emu/dolphin/pull/1479.diff

Or download a build (Windows)
https://dl.dolphin-emu.org/prs/pr-1479-dolphin-latest-x64.7z

comex has created an alternative fix. Would you please also test his fix?

https://github.com/dolphin-emu/dolphin/pull/1483

Download a build (Windows)
https://dl.dolphin-emu.org/prs/pr-1483-dolphin-latest-x64.7z

Unfortunately I cannot test the "Comex fix" because for me too master 4035 is broken: https://forums.dolphin-emu.org/Thread-instant-crash-after-pr-1478-4-0-4035-and-newer-builds

I was able to test the "Comex fix" and confirmed audio is still good in SMS on both of my low-end systems. Seems to run a little faster too.

Could you re-upload the "Comex fix" based on a 4.0-4041 dirty? (now master works again)
Thanks

This seems to be fixed in 4.0-4647.

I can confirm everything is working for me now. I can play the game with widescreen hack, heat visual effect fix, vsync and HLE and the game runs better than ever.

Thanks!

Your PC is too weak, you need a better PC.
Here is a good PC.
Intel Pentium CPU G630 2.70GHz
NVIDIA GeForce GT 520 Overclocked 5.49GHz
8GB RAM
Soundcard: YES
The game works fine with EFB to RAM and LLE Audio.
Try running the emulator as administrator.
I am using Dolphin 3.5-367