Frequent audio popping and clicking sounds in most games.

[orbea]

What happens?

In many (Most?) games I experience often frequent minor audio popping and clicking sounds. This is highly distracting and makes it harder to enjoy games.

I have tried most settings and the only one that seems to make any clear impact is disabling Audio sync (resampling) which only helps a little. Both OpenGL and Vulkan are affected as well as both the SDL and Qt frontends. I also tried PR #12602 which did not help.

I tried going back to v1.0 without finding a good commit.

I can always reproduce it on the title screen for Lunar Silver Star Harmony where the FPS and speed counter is a solid 60 and 100% respectively.

Other games I have experienced in are:

• Growlanser: Wayfarer of Time
• Legend of Heroes Ao no Kiseki
• Nayuta: Endless Trails
• Riviera The Promised Land
• Tales of Eternia (Rare)
• Tales of Rebirth
• Tekken 6 (Rare)
• Valkyrie Profile

One game I have not noticed it in is Guilty Gear XX Accent Core Plus.

What should happen?

Audio should be smooth and not suffer from popping or clicking sounds.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

OS: Slackware64-current
GPU: RX Vega 56
CPU: AMD FX-6350
compiler: clang-10.0.0, gcc-9.2.0
mesa: https://github.com/mesa3d/mesa/commit/461ee852486da724c79c5145fa2e50bdfa54aa55
llvm: 10.0.0
alsa-lib: 1.2.1.2
Qt: 5.14.1
SDL: 2.0.10
ppsspp: d0e2aa3

[orbea]

Issues #9736 and #10865 seem familiar, but maybe are different.

Can this PR #8717 helps this issue?
sorry for asking 😅

[orbea]

That PR has a lot of conflicts making it harder to test, but thanks for pointing it out!

[quicksilver7837]

I get the same behavior running ppsspp on my raspberry pi 4. Certain games even when running fullspeed, the audio will make popping noises. The audio pops even when the sample audio plays for certain games while navigating the game selection menu.

[unknownbrackets]

Well, even if you see 60/60 or 100%, that's an average. If you drop a single frame, you'll probably hear a pop even if you don't see it visually and even if it isn't enough to change the average.

If you enable the devmenu button in developer settings, you can turn on a "frame times" graph. Do the pops correspond with that graph in any way?

-[Unknown]

[quicksilver7837]

It's hard to tell, though that does make sense. However, why would the sound be popping when it plays the preview audio on some titles in the game select area of the ppsspp menu? It's only playing audio and nothing is happening on the screen so I can't imagine it's that taxing, though I am not an expert on the matter.

[orbea]

Well, even if you see 60/60 or 100%, that's an average. If you drop a single frame, you'll probably hear a pop even if you don't see it visually and even if it isn't enough to change the average.

Sometimes it shows 99.9% or 100.1%, but this not seem to directly correspond to the pops.

If you enable the devmenu button in developer settings, you can turn on a "frame times" graph. Do the pops correspond with that graph in any way?

No, it does not seem to correspond to the graph in any way.

[orbea]

@unknownbrackets Actually with the audio debug from the dev menu, the number of overruns will increase by one with every pop.

[unknownbrackets]

Is the sample rate constant at 44100 or does it fluctuate slightly within +/- 10? Are you often seeing audio buffer above 2000 or is it usually below 2000 and sometimes jumping above 2000?

An overrun would mean audio buffer went up to 8192/8192. That basically shouldn't happen.

Architecturally, it works like this:

• The PSP game produces audio data in small bursts, and sends this to PPSSPP's audio system.
• PPSSPP resamples this (if necessary) to keep it smooth, and keeps it in a buffer - that's the 8192 number.
• The platform glue (this part differs on SDL, Qt, retroarch, Windows, Android, iOS, etc.) pulls this data off the buffer whenever it is ready to play more audio, and sends it to the OS.

Often a larger buffer is needed to bluetooth or wireless audio, because it can't stream audio quite as immediately. This is why it's 8192 - it should not normally use that much buffer unless you have audio latency somewhere in your setup.

An overrun means that the buffer was full. So it means that the platform glue or OS was not taking enough data fast enough. An underrun would mean the opposite - that the emulation wasn't keeping up, and couldn't produce enough audio to keep the buffer moving.

It's possible this is an issue only with SDL and Qt.

To confirm this, it might be worth trying PPSSPP in WINE. If that works well, it really points to a problem in how data is being sent through on SDL and Qt.

-[Unknown]

[orbea]

Is the sample rate constant at 44100 or does it fluctuate slightly within +/- 10?

It never changes.

Are you often seeing audio buffer above 2000 or is it usually below 2000 and sometimes jumping above 2000?

It fluctuates with such speed I can't clearly read it, but from my screenshots it seems most are between 1000 and 3000, one was nearly 4000. I do not notice it reaching 8192 at all.

To confirm this, it might be worth trying PPSSPP in WINE. If that works well, it really points to a problem in how data is being sent through on SDL and Qt.

Trying 1.9.3 in wine-staging-5.0 and I am not experiencing any clicks or pops in the Lunar title screen. The sample rate fluctuates +/-10 around 44100 and the audio buffer is equally unreadable. It is not also not constantly registering overruns.

[unknownbrackets]

Do you have the audio resampler setting enabled (it should be on by default)? That's what would make the sample rate fluctuate, as it tries to match actual speed.

-[Unknown]

[orbea]

With wine it was the default so it was enabled, with SDL I had it off because it makes this problem worse. When enabled in SDL it reports the sample rate as fluctuating between about 44280 and 44300 and the problem is clearly worse.

[unknownbrackets]

#10865 also describes the sample rate going over 44200 and a similar issue on Android.

The resampler increases the rate if there's more data in the buffer, meaning that it's reading PSP audio data faster to drain the buffer (keep it from overrun.) In theory this means your device is playing at below 44.1kHz.

That it happens more frequently when the resampler is enabled is interesting, though. Does the audio buffer look to stay below 3000 when it's enabled? Do overruns still correlate with the pops?

-[Unknown]