Emulator

Can you bisect to find when it stopped working?

If you're on windows and can't (easily) use git bisect, use this https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds

And yes, please bisect this.

4.0-8327 broke it

https://dolphin-emu.org/download/dev/cc3dc05438b9324075c873cc42e72fd465b04990/

ASSympt0te wrote:

https://dolphin-emu.org/download/dev/cc3dc05438b9324075c873cc42e72fd465b04990/

Sorry, wrong link
https://dolphin-emu.org/download/dev/cb5be45f728ae282177c31daded54fbce1e5285f/

May you check your configuration value for the option "TimingVariance"? It should be 40ms. In this case, this PR has (almost) no effect.

It's 40. I tried changing it around from 10 to 100 and they all have the issue.

Chaning MAX_SAMPLES back to 2048 instead of 4096 stops it from happening

Does this audio crackling happen on a real Wii?

I'd like to get this confirmed before we change something which isn't correct.

Can confirm the audio crackle doesn't happen on Wii.

About the issue: We send the correct amount of samples triggered by coretiming. But within https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/DSP.cpp#L432 , we also send samples on enable/disable the DMA. So if a game enables/disables very often, we send more samples than expected. No idea if this line is just wrong, or if we need to restart the coretiming event on every enable/disable action.

This looks like the same bug affecting neogeo games.

I tried the PR that seemed to fix this and it didn't affect the neogeo titles unfortunately.

I don't think it is the same bug. This affects LLE and HLE, neogeo bug is exclusive to HLE.

I'm pretty sure loading samples on enable/disable DMA is correct, but I think the AudioDMACallback which runs at 4khz needs to have it's phase adjusted to match the timing of enabling the DMA.

If the homebrew is ignoring the Audio DMA interrupt + latching for correct timing (which will quickly force any game into whatever phase that dolphin chooses) and is using timers to manually trigger the Audio DMA at the correct time... you could get issues.

So... I've looked into this.

Dolphin currently latches the new values onto the Audio DMA at the start of a new transferer. Because this Homebrew hasn't updated the buffer, dolphin goes back to the start of previous buffer and loads the entire thing (512 samples). Then dolphin fires the Audio DMA interrupt.

The game sees this interrupt and stops the Audio DMA, loads the new address into it and starts a new transfer.

I've experimented and it looks like the re-latching interrupt is meant to fire soon enough that this homebrew can successfully restart the DMA at a new address before any samples are read out of memory.

Was the status of this ticket supposed to be set to Fixed or is there more to investigate here?