Mupen64plus's audio popping (Windows 10)

[AmbientMalice]

I've been testing Indiana Jones, and the game has noticeable crackling. You hear popping as soon as the Indiana Jones logo comes up. Then I tested a bunch of other games, and there's popping and crackling all over the place. Even something like Ocarina of Time sounds wrong, with weird skipping at points. The internal speed-limiter seems pretty borked, since GLideN64 reports the thing flailing between 59-61VIs all the time. Has anyone else experienced this? I wanna be sure this isn't some Windows 10-specific issue, since Win 10 did cause problems for some emulators. A lot of people have complained about mupen64plus's audio in the past in various corners of the internet, but this is the first time I've sat down and actually done some testing. I tried tweaking the Windows timer value, but that didn't do any good. Games are still popping.

[loganmc10]

I personally don't really notice any issues. I assume you are using the m64p package?

When using GLideN64, there is going to be some popping the first time you play a game because the shader compilation causes stuttering. The next time you play the game it shouldn't be there, this is probably why the Factor5 logo stutters in Indi (that's when it pops for me anyway, but only the first time). If you have shader storage off in GLideN64 it's going to happen every time.

Same thing in OoT, in the opening cutscene, right when Link riding the horse appears, there is a pop, caused by shader compilation.

But in terms of overall usage, it seems ok in my testing

[AmbientMalice]

It also pops with Angrylion's.

[loganmc10]

But again, it could be because the emulator isn't maintaining a steady 60FPS because of performance reasons. I don't even own a machine that can handle Angrylion at a constant 60FPS so I can't test that (the performance of Angrylion isn't so great with mupen64plus to begin with).

Basically I think we would need to test with a lighter-weight GFX plugin like Rice or Glide64 and determine if the pops are happening because of performance reasons, or if it's because of the speed limiter or emulator timing or something else.

[AmbientMalice]

I'll close this issue for now and do some more testing. What I find puzzling is how the popping seems quite random. I'm dubious that it's a shader cache issue because once it starts, it starts happening regardless of whether the game has been run before or not. It could be related to save states or some other factor. I do think there is something wrong, though.

[loganmc10]

There are probably some things that could be done in the audio plugin to counter some of these issues, but unfortunately I don't have much time lately to look into this sort of thing.

For some context, the audio plugin that I use in the m64p package (I called it audio-sdl2) has a bit of code to try and deal with these issues:

https://github.com/m64p/mupen64plus-audio-sdl2/blob/master/src/main.c#L335-L365

It tries to keep the buffer size between 20ms and 300ms, so that if there is a hiccup, there should be a 20ms buffer that can keep playing, to try and avoid pops. Increasing that value may help, but it would also increase the audio delay (the audio plays slightly late). In mupen64plus-ae, audio stretching is used to try and avoid these issues.

[AmbientMalice]

Something is off... I'm testing Indiana Jones with both Angrylion's and GLideN64. Angrylion's is only loading the CPU to 50%. GLideN64 is like 10% But every single time wolves howl in the background, the audio starts popping. And it pops at other times, too, but usually after a delay. It seems to me that any game will start popping if you idle long enough.

There's probably something wrong with the frame limiter. (As I mentioned, games often jump between 59 and 61VIs. It's not that the emulator can't hold 60VIs. It's that it isn't staying below 60VIs.

It's probably related to this issue.

#397

I've seen several people on 4chan claim that mupen64plus has popping audio for them, so I don't think this is an isolated problem.

[loganmc10]

You can also try changing the CountPerOp setting to see if that improves the situation.

[AmbientMalice]

You can also try changing the CountPerOp setting to see if that improves the situation.

Doesn't seem to have any effect, unfortunately. It was one of the first things I tried.

[fzurita]

Can you try my version of sdl2? It has audio time stretching:

https://drive.google.com/file/d/1MAGd6KJtE4cJxsBmbjntIdMBLe7yZB2A/view?usp=sharing

And the source code if you are interested:

simple64/simple64-audio-sdl2#3

[AmbientMalice]

Sure, I'll give it a try. That said, isn't the idea behind time stretching to fix the emulator running slower than normal? I think the problem here might be that the emulator is running too fast.

[AmbientMalice]

Well, timestretch removes the popping a the cost of pretty glaring audio latency. (With default settings). Setting Secondary Buffer NBR from 20 to 5-10 somewhat improves the audio latency at the cost of hearing occasional popping.

[fzurita]

Can you try changing the sampling rate to different values? Also disabling the audio time stretching may help with the latency as well.

Interestingly, I don't get any noticeable audio latency in my PC.