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.

[smbhax]

With the Mupen64Plus v2.5.9 Win32 release, I getting some audio popping when playing WWF No Mercy, particularly after running for a while, doing some wrestler edits and running some matches, and so forth; at that time, I noticed a stream of messages in the console like this:

"Audio Warning: sdl_push_samples: pushing 1624 bytes, but only 244 available !"

but with different numbers.

(The "pushing" Audio Warning messages were similar to the warnings I get if I set "SECONDARY_BUFFER_SIZE = 4096" in the .cfg when building and running from the latest code.)

Tried messing with the PRIMARY_BUFFER_TARGET setting in the mupen64plus.cfg, but raising it to reduce drop-outs increased audio latency dramatically in v2.5.9 Release.

I noticed that although mupen64plus.cfg lists a variety of resampling algorithms, including src-sinc-fastest and speex-fixed-{10-0}, when I try these in v2.5.9 Release, the console prints a message like

"Audio Warning: Could not find RESAMPLE configuration speex-fixed-10; use trivial resampler"

This commit from 2018

RetroPie/RetroPie-Setup@a6108c2

seems to refer to using src-sinc-fastest to fix audio-sdl crackle--but that resampling algorithm doesn't seem to be supported in v2.5.9 Release.

I had the same problem at first when building and running from the latest code, even though I had I think installed the libsamplerate package for Mingw64 in MSYS2; I went and installed libsamplerate for all MSYS2 environments, built, and then I was able to use the src-sinc-* resamplers.

In building and running from the latest code, I didn't find any combination of .cfg BUFFER and RESAMPLE settings that eliminated popping; however, these settings

DEFAULT_FREQUENCY = 48000
PRIMARY_BUFFER_TARGET = 16384
SECONDARY_BUFFER_SIZE = 2048
RESAMPLE = "src-linear"

seemed to do about the best at reducing pops to more muted squelches, without introducing definitely perceptible audio latency. The src-sinc-* resamplers, particularly src-sinc-best-quality, seemed to introduce more latency at those larger buffer sizes, without noticeably better pop reduction.

Even with those settings and using the latest code, however, I still get some popping, and streams of audio warnings in the console after playing for a bit sometimes, such as

Audio Warning: sdl_push_samples: pushing 1384 bytes, but only 1108 available !
Audio Warning: sdl_push_samples: pushing 1520 bytes, but only 1476 available !
Audio Warning: sdl_push_samples: pushing 1848 bytes, but only 1620 available !
Audio Warning: sdl_push_samples: pushing 1392 bytes, but only 1196 available !
Audio Warning: sdl_push_samples: pushing 1896 bytes, but only 1452 available !

[Jj0YzL5nvJ]

The tests done with the Release version are not useful. You can download the nightly-build's manually or use this batch script (it requires 7-Zip installed).

The bugs you report also appear from time to time in nightly-build versions, but they are not consistent. But you can also try other alternative audio plugins...

First try with: https://github.com/Jj0YzL5nvJ/mupen64plus-audio-sdl/releases/tag/test_no_memmove
It's derived from mupen64plus/mupen64plus-audio-sdl#36

P.S: Remember to delete your previous Audio-SDL configuration and run with --audio mupen64plus-audio-sdl-test.dll.

[smbhax]

Thanks! = D

Yeah, I'm not going to be using the Release version any more; I'll be building my own from source, as I did for some of those results--as indicated--in my earlier comment.

I've looked at the nightly-build before, but I'm confused by it as it doesn't include an .exe. The last time I tried dropping the files it did have on top of v.2.5.9 release--last week some time, I think; not sure that's what you're supposed to do with it, but I didn't know how else it was meant to run--it gave errors when I tried running with the Release v2.5.9 exe.

(The other confusing thing about the nightly-build entry on the Releases page is that its main displayed date doesn't update--it's still on April 11, 2022--but I eventually figured that part out.)

I gave the test_no_menmove files a try over my freshly built-from-source files, having first deleted everything from the Audio-SDL section of the .cfg, as you instructed--it filled it in with "RESAMPLE = "speex-fixed-4," for instance, when run--but the occasional audio pops and snaps remain more or less the same as before in WWF No Mercy.

[Jj0YzL5nvJ]

Try with: https://github.com/Jj0YzL5nvJ/mupen64plus-audio-sdl2/releases/tag/nightly-gen-smp64

What video plugin are you using BTW?

[smbhax]

That one seems pretty good--the pops occur but are pretty subdued, and there doesn't seem to be noticeably increased audio latency. I'm not sure it's too much different than what I've been able to get in the default plugin with

DEFAULT_FREQUENCY = 48000
PRIMARY_BUFFER_TARGET = 16384
SECONDARY_BUFFER_SIZE = 2048
RESAMPLE = "src-linear"

but it's reasonably comparable in my routine WWF No Mercy test, at least.

For video, just the regular

VideoPlugin = "mupen64plus-video-glide64mk2.dll"

[Jj0YzL5nvJ]

For many, "the regular" is GLideN64. Rice and any Glide64* is more like legacy support... For some, "the new regular" is ParaLLEl RDP... "it comes in many flavors".

Now try:

• --audio mupen64plus-audio-sdl.dll --rsp mupen64plus-rsp-cxd4-sse2.dll --set rsp-cxd4[DisplayListToGraphicsPlugin]=True
• --audio mupen64plus-audio-sdl-test.dll --rsp mupen64plus-rsp-cxd4-sse2.dll --set rsp-cxd4[DisplayListToGraphicsPlugin]=True
• --audio simple64-audio-sdl2.dll --rsp mupen64plus-rsp-cxd4-sse2.dll --set rsp-cxd4[DisplayListToGraphicsPlugin]=True

Different RSP can offer different audio results... you need LLE RDPs plugins for LLE RSPs.

HLE RDPs:

• video-arachnoid (barebones...)
• video-glide64*
• video-GLideN64 (With HLE RSP)
• video-rice

LLE RDPs:

• video-angrylion-plus
• video-GLideN64 (With LLE RSP)
• video-parallel
• video-z64 (not good...)

HLE RSPs:

• rsp-cxd4* (--set rsp-cxd4[DisplayListToGraphicsPlugin]=True)
• rsp-hle
• rsp-z64-hlevideo (slow?)

LLE RSPs:

• rsp-cxd4* (--set rsp-cxd4[DisplayListToGraphicsPlugin]=False)
• rsp-parallel
• rsp-z64 (very slow)

Good night...

[smbhax]

I seem to get better results with Glide64 than GlideN64, that's one reason why I switched from Project64 to Mupen. (I think I actually like Rice better than Glide64, but some polygons sometimes come out untextured in No Mercy when using it, and I haven't been able to find any settings for it that cure that.) And I'd tried Simple64 with its Parallel implementation and didn't really like its particular pixelization effect in No Mercy.

Thanks for explaining the RSP thing! ^ _^ I hadn't had any clue what those were. I tried the option strings you listed, and other combinations of the (not-bad) RDPs, RSPs, and the various audio plugins, based on your HLE/LLE breakdown of the RDPs and RSPs. I didn't find any combination that gave better results than I'd achieved previously for the occasional audio popping I'm getting in No Mercy, and some of them were definitely worse.