Project

General

Profile

Emulator Issues #9410

Audio Crackling in Homebrew Demo, not present on 4.0.2

Added by ASSympt0te over 4 years ago. Updated over 4 years ago.

Status:
Accepted
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

GRLLib 4.3.0 Demo Presentation

Game ID? (right click the game in the game list, properties, info tab)

http://www.pouet.net/prod.php?which=55527

What's the problem? Describe what went wrong.

Using HLE or LLE, XAudio2 and OpenAL results in audio crackling when running the program, even though VPS and FPS remain a solid 60

What steps will reproduce the problem?

  1. Enable Virtual XFB, EFB2RAM (Required for proper video emulation)
  2. Start the dol, and listen

Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?

4.0.2 - No issue on LLE or HLE (although video emulation is incorrect)

What are your PC specifications? (CPU, GPU, Operating System, more)

i5-4670k @ 4.4GHz
GTX 780
Windows 10

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

Nope :(

History

#1 Updated by MayImilae over 4 years ago

Can you bisect to find when it stopped working?

#2 Updated by Helios over 4 years ago

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.

#3 Updated by ASSympt0te over 4 years ago

4.0-8327 broke it

#6 Updated by degasus over 4 years ago

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

#7 Updated by ASSympt0te over 4 years ago

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

#8 Updated by ASSympt0te over 4 years ago

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

#9 Updated by JMC4789 over 4 years ago

  • Assignee set to degasus
  • Priority changed from Normal to High
  • Milestone set to Current

Please investigate this, degasus.

#10 Updated by Fog over 4 years ago

Does this audio crackling happen on a real Wii?

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

#11 Updated by Fog over 4 years ago

  • Status changed from New to Accepted

#12 Updated by JMC4789 over 4 years ago

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

#13 Updated by Fog over 4 years ago

  • Status changed from Accepted to Fix pending

#14 Updated by degasus over 4 years ago

  • Status changed from Fix pending to Accepted
  • Assignee deleted (degasus)
  • Priority changed from High to Normal

The bisect is wrong, this commit makes the stutter worse, but it's not the source of the issue. AI sends more DMA samples than expected, likely because of the homebrew very often enables / disabled DMA streaming: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/HW/DSP.cpp#L432

So the linked patch is wrong.

#15 Updated by JosJuice over 4 years ago

  • Milestone deleted (Current)

Unless this affects more than some homebrew, I don't think it should be a 5.0 blocker.

#16 Updated by JMC4789 over 4 years ago

  • Milestone set to Current

Until we know what we're doing wrong on this, it'd be nice to keep it current as there are games suffering from stuttering.

#17 Updated by JMC4789 over 4 years ago

  • Milestone deleted (Current)

Okay degasus explained why current was dropped.

#18 Updated by degasus over 4 years ago

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.

#19 Updated by JMC4789 over 4 years ago

This looks like the same bug affecting neogeo games.

#20 Updated by JMC4789 over 4 years ago

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

#21 Updated by ASSympt0te over 4 years ago

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

#22 Updated by phire over 4 years ago

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.

#23 Updated by phire over 4 years ago

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.

Also available in: Atom PDF