Severe Slowdowns in GBA Emulation

[nickkeane]

RetroArch: 1.20.0
Core: mGBA (72b5a9d)
OS: Windows 11 x64
CPU: Intel i9 14900H
GPU: nVidia RTX 4070 Laptop

GBA games are experiencing severe slowdowns with the latest update:

• Advance Wars
• Advance Wars 2
• Breath of Fire II

Other games, like Castlevania: Circle of the Moon, seem to be running fine.
Game Boy and Game Boy Color games seem to be running fine as well.

[endrift]

Definitely fallout from 72b5a9d#diff-0453db1a65691e79b26cacd96f6e41ddd4ad89afa83bc2688ddb9593f8051f15R1433. The games are probably running at half-speed because it's trying to resample the audio rate wrong.

[warmenhoven]

Yeah sorry about that. Android was crashing (actually I have a suspicion that it wasn't android specific, just that's where all the reports came in from). I was hoping I'd be able to simply bypass the resampling and let the front end handle it entirely but of course that doesn't work. It worked for gb/gbc so I incorrectly assumed it worked generally.

I've put in what I think is more of a workaround where setting the audio rate change handler happens in the deferred setup, which both fixes the android crash and seems to run at proper speeds now (I've tested Advance Wars and a couple other games, on both android and Mac).

[endrift]

fyi the ideal game to test this with is Konami Krazy Racers, as it changes the audio rate several times throughout. Compare it against the standalone to see if it works properly.

I will note that if it crashes on Android when the audio rate change handler is called, that's a RetroArch bug, not a core bug.

[Awakened0]

fyi the ideal game to test this with is Konami Krazy Racers, as it changes the audio rate several times throughout. Compare it against the standalone to see if it works properly.

There's still some nasty hitches and sound crackling in that game with the latest Windows core that aren't in the one before this big update. When selecting a character there's a hitch and crackle, the white screen crackles before the track loads, another hitch before the first light turns red and a couple more hitches a second after you first gain control.

Old core (0.11 dev 747362c):

Old.mp4

New core (0.11 dev 945fa70):

New.mp4

[warmenhoven]

There's still some nasty hitches and sound crackling in that game with the latest Windows core that aren't in the one before this big update.

Good news, I can reproduce this on Mac and iOS as well. Also, I can reproduce this with the current mgba-emu/master branch (all the default build options except -DBUILD_LIBRETRO=ON).

I will note that if it crashes on Android when the audio rate change handler is called, that's a RetroArch bug, not a core bug.

Well yeah sort of. But also calling RETRO_ENVIRONMENT_SET_SYSTEM_AV_INFO causes a full driver reinitialization, and doing that while it's trying to initialize the drivers while bringing up the game is bound to cause problems. (libretro.h specifically says "This can only be called from within retro_run.") Setting stream.audioRateChanged in retro_init causes it to get invoked in retro_load_game.

Anyway I'm going to investigate good solutions for dealing with audio rate changes without doing the full driver reinitialization.

[warmenhoven]

Ok, I've put in a change that uses audio-resampler in the core, rather than passing it off to the frontend to do, and from what I can tell it seems to fix all of the problems with the hangs and audio glitches.

[Awakened0]

The hitches and sound crackles are indeed fixed!

But the sound is much more "muffled" sounding. Sort of like when turning on the low pass filter option. But I made sure that was off when comparing both cores.

Old (747362c):

Old.747362c.mp4

New (7f20e53):

New.7f20e53.mp4

Here's my audio settings on Windows (I've found WASAPI causes a weird warbling sound effect with my VRR setup, so I stuck with xaudio):

[endrift]

Most GBA games use the hardware sample rate of 65536 instead of 32768, so you should probably use that instead. The motivation for not doing any resampling in the core was to avoid having to do this double-resampling leading to loss like the above. Technically the internal sample rate can go even higher, but that's well above human hearing so 65536 is probably fine to use for the intermediate. I detailed the audio rate stuff in the 0.10 release article: https://mgba.io/2022/10/11/mgba-0.10.0/#improved-audio-emulation

[warmenhoven]

Thanks. Yeah it's not great but when the alternative is a full driver reinit, I figured this was the lesser of two evils. FWIW the mupen core does exactly the same thing, it's where I stole the idea from.

[endrift]

Yeah that's fair enough.

[Awakened0]

Latest commit brightened the audio a decent amount. Still not the same clarity as the old build, but pretty good. Compare this with the two examples above.

Latest (0f39405):

New2.0f39405.mp4

[RenanSD007]

In this new version the fast-forward speed in Pokémon Emerald decreased a lot, so I had to go back to the previous version (fortunately I had a backup)

[warmenhoven]

fast-forward speed in Pokémon Emerald decreased a lot

Can you quantify that? I haven't tried the old core but with the current one I'm getting around 1400fps.