Crackling sound after a while

[Tatsuya79]

Sound crackles in many situations. My reference test is Super Mario 64 DS Ghost House level. I did a savestate there and tried various Sync options and buffer sizes but it always crackles.

Stand-alone current git for win x64 with default settings is OK. (even with no Interpolation and no advanced SPU logic)

Tested on win7 x64 current RA and Desmume nightly, soft and GL rendering.

[Tatsuya79]

Sound was good in the old desmume libretro port at that time in that branch https://github.com/Tatsuya79/desmume/tree/old_SPU

[bearoso]

Is this before and after the changes yesterday? Can you upload your save state somewhere? I don't have access to save data for the ghost house level.

[Tatsuya79]

sram and state: https://mega.nz/#!ktVRmRKC!PywDGtR-Hyf11YMlDPxKTcj_ZEJ7Vo7vLcWOr-qwIaE

It happens since the beginning, not caused by yesterday change. I tried every sync modes and they do the same.

[bearoso]

This is really bizarre. I load your state and hear the crackling, but if I enter the ghost house from the battery save it's not there. I make my own state at the same point and there's no crackling.

[bearoso]

I just tried in Windows (10). There's something weird about that save state. How old is it? Can you try going to the ghost house from the battery save on your system using the latest version and see if the crackling is still there?

[Tatsuya79]

Oh damn you're right! It was a savestate of the day before yesterday, I didn't think the sound sync could affect it. I did a lot of testing bringing back the old code into the SPU with that savestate lol.

I think I can close that now thank you.

[Tatsuya79]

...and re-opening cause I have the crackling back after loading a fresh new state. It's less obvious than before but it's there in the high range after loading savestates. Loading sram, sound is ok.

Savestates get corrupted? they screw the timing of the audio?

[bearoso]

Could be some sound state isn’t properly saved. Will have to look into it. It’s probably in standalone version, too.

[Tatsuya79]

Can't seem to reproduce on stand-alone.

[bearoso]

Ok, what I've done is short-circuit the audio in a similar way to how your old branch did. This avoids all the built-in audio stretching that's unneeded in retroarch and which doesn't work very well anyway.

Your old save state still produces scratchy sound, but any new ones I make by spamming the save/load state buttons remain free of any crackling. If you can't make a new state that exhibits the crackling, we can close this. If you can, it's something I can't reproduce and someone else will have to fix it.

[Tatsuya79]

I found the place that started the crackling and got there again without loading a state and it messes up the sound just the same. (I'm on the most recent commit) It happens in the fight against King Boo, made a savestate just before entering the hole, the sound is still good.

I'll try if that happens in stand-alone too, but yesterday I did that same fight and it did not happen.

[Tatsuya79]

Nope can't reproduce in stand-alone.

[bearoso]

I can't reproduce it. I started from your save state. In the king boo fight I can't hear any crackling. After the boo fight I can't hear any crackling. I reenter the ghost house and the weird music still sounds fine.

What build are you running at the moment, is it your own? Can you post your retroarch.cfg and retroarch-core-options.cfg so I can see your setup?

[Tatsuya79]

It seems it's random, took me 4 times to trigger it this time damn. retroarch.cfg core-options

cfg override

video_hard_sync_frames = "1"
video_frame_delay = "0"

[bearoso]

Well, your core options aren't updated with the latest ones I added, so you're probably not running the latest build. edit Seems you updated that, so never mind.

Aside from that, I notice your jit block size is 15, while 12 is recommended for compatibility and is the Desmume default. Your 15 is probably left over from the old default. I'll probably cap that option at 12, given the things it can break. You might see if the interpreter or a lower jit size fixes it, considering that's our primary source of indeterminacy, and the crackling is a random occurrence.

[Tatsuya79]

I played a bit with JIT at 12 (loading from sram) and the crackling happened again after a while. So no clue. :confused:

[bearoso]

I’m a a loss. I can’t get it to start crackling on my end in either Linux or Windows 10, but it’s definitely there in your save state so I know you’re not crazy.

It must be something that can be preserved as part of the state, so it’s probably in the core and some setting we’re not matching like-for-like with the standalone version. But I don’t see much difference in your configs, so I’m puzzled why it happens on your system and not mine.

[bearoso]

I've changed to the mapped jit functions like standalone does now and worked around the compiler bug in mingw. This might make the jit more behaved and fix it. You could also try the interpreter and see if you can reproduce it there.

At this point we're doing everything exactly like the standalone version. The only difference is the compiler. Clang works properly with mapped jit blocks and strict aliasing enabled, so I know mingw64 gcc's optimizer is flaky. MSVC might be an option as well.

[Tatsuya79]

Still happens, haven't tried Interpreter yet. This is the compile log with msys2 gcc 7.3 in case there's anything helpful. Grabbed the buildbot dll too and the issue was there as well.

Something I noticed, if you close the lid (L2) and open it again the sound will be screwed up.

edit: it happens with interpreter too, crackle less though.

[bearoso]

The lid thing is in standalone, too, so I'm not sure what to do about that; I didn't reverse engineer it.

[bearoso]

I can load your old state with the crackling and the interpreter turned on and there is no noise. I think something is going on with the JIT. Desmume standalone doesn't enable it by default.

[Tatsuya79]

Good news, well not really, I could reproduce it in stand-alone with JIT enabled. And it still crackles if I load the state I take. Switching to interpreter removes almost all.

So yes, that was an upstream problem, sorry for that waste of time. :confused:

[ghost]

@Tatsuya79

If you came to the conclusion that it was an upstream issue, your efforts have not been in vein and you have not wasted anyones time.