What is that setting even for?

I seem to remember someone mentioning a bug about some audio setting or code in libretro/retroarch that caused crashes, but it was a while ago. Not sure if it's the same one.

That said, I think there have been various issues with save states and graphics resets in libretro. One problem is that libretro/retroarch are not designed for emulators that use threads, but rather for emulators of older systems. Using libretro/retroarch apparently also disables a lot of graphics features we use, as users have reported being stuck with OpenGL 2.x feature sets.

-[Unknown]

That setting keeps the speed of the audio consistent with the game; without it, the audio speeds up slightly but noticeably.

Are you thinking of this issue? It’s what got me to look in the audio settings, but it deals with having the mixer enabled, not audio synchronization; this crash doesn’t seem to have anything to do with that.

Yes, that's exactly what I was thinking of.

Hm, PPSSPP just sends audio as it's generated by the game (games generate short bursts of audio data throughout each frame.) PPSSPP itself synchronizes everything based on display refresh. But notably, PSP games ran at 59.97 so if libretro is forcing 60 FPS even, you'll have 0.05% less audio than expected each second (the game will also run that much slower than it did on a real PSP.) Actually, or it might be more depending on how it forces. But either way, I'd guess that's the cause of the sync issue.

Presumably the setting controls how libretro reacts to buffer underruns (i.e. when it is looking for that missing 0.05% of audio), but I'm not sure how that would result in crashes.

-[Unknown]

There’s a setting in RetroArch (Video > Synchronization > Sync to Exact Content Framerate) that, well, syncs up the game’s framerate and makes it so audio synchronization doesn’t have to be enabled (I also realized that part of the reason why the audio is desynced so much is that I use a 75 Hz monitor; setting the refresh rate to 60 Hz also doesn’t desync audio).

Also, with “Synchronize Audio” disabled, restarting works fine unless I spam it. RetroArch crashes when rewinding, and enabling support for rewinding seems to make the games speed up heavily. Savestates and closing the game and RetroArch all seem to work fine.

I should probably just switch to standalone PPSSPP, it doesn’t have any of these problems.

I will note that rewind, even in PPSSPP proper, may impact performance a bit. Internally, that just creates periodic save states automatically. Even compared to the PS1, the PSP had significantly more RAM - and this just takes time to save. If your device's RAM and emulation is fast enough, it may fit within a frame with the emulation... but otherwise you may experience dropped frames.

I'm not sure why enabling libretro's rewind would speed things up, though. Unless your device does thermal throttling.

-[Unknown]

Seems to be more of a problem with Retroarch, seeing as disabling audio syncing also fixes the Yaba Sanshiro core from crashing on exit.

Good luck getting it fixed, I reported that loading save states (and only loading, saving worked fine) was broken over 2 years ago, right when a new commit broke that feature, and nobody bothered to try to figure out what the problem was. I came here looking to see if it had been solved yet, only to find the original issue completely removed (not closed). I'm amazed you figured out a fix, however, your solution does not work for me. With audio sync disabled, and 'Sync to Exact Content Framerate' enabled, the game seems to run in fast forward.

Wise move to switch to the standalone. The RetroArch core doesn't seem to get much maintenance.

Edit: Actually, with the latest RetroArch and latest PPSSPP, both save and load states DO work for me, with no settings needing to be changed.

However, using RetroArch's autosave feature, to automatically save a game on exit (so that you restart where you left off later) does NOT work properly (I suspect RetroArch completely closes before it can happen), and trying to manually load your auto save state (if you have auto load state turned off) makes the game hang/crash.

Your problem of RetroArch crashing when you reset the game happens for me with Audio Sync enabled, but not when manually closing RetroArch or hitting escape. Enabling rewind causes no problems on my end, but, as you mentioned, performance takes a hit.

A somewhat crude way to solve the fast forwarding issue would be to increase the Vsync Swap Interval value, but I definitely wouldn't recommend doing that over simply using the standalone version.

I don't know if it is the same issue on Android's Retroarch PPSSPP core or not, but when I turned off "Audio synchronization" the "Close content" function immediately works, but with "Audio Synchronization" enabled, there will be a freeze of the retroarch so that I'll need to force quit. The function "Sync to Exact Content Framerate" cannot help the content to be run in right FPS when Audio Sync is turned off.

This bug seems appeared for a long time. I hope anyone would help to fix it.

I can confirm this issue still exists. Disabling audio synchronization fixes the problem, but the game starts to run with double speed.

Also still happening on my end (Android, windows works fine), crashing when closing content. Disabling audio synchronization let's you close content normally, but the game's fps is super sped up. Turning "Sync to exact content framerate" does not help normalize the game speed.

I had this issue at one time, then when I updated the core on 5-17-2020 (that is the 'date modified' in windows), save and load states worked once again without issue. I tried updating the core the other day, and load states once again crashed games. Luckily I had backed up the core from 5-17-2020.

Whoever is responsible for updating this core is obviously not paying much attention to this.

Idk if it helps, this is what I get on my Linux VM with gdb (it doesn't seem to crash on Windows, or more rarely anyway):

(gdb) bt
#0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555557f636fc) at ../sysdeps/nptl/futex-internal.h:183
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x555557f636a8, cond=0x555557f636d0) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0x555557f636d0, mutex=0x555557f636a8) at pthread_cond_wait.c:647
#3  0x00007ffff4ad0e30 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007fffe770640f in GLRenderManager::ThreadFrame (this=0x555557f63650) at ../Common/GPU/OpenGL/GLRenderManager.cpp:218
#5  0x00007fffe7ec7cb8 in LibretroGLCoreContext::ThreadFrame (this=0x555557a50190) at ../libretro/LibretroGLCoreContext.h:24
#6  0x00007fffe7ebd64f in Libretro::EmuThreadStop () at ../libretro/libretro.cpp:578
#7  0x00007fffe7ec7510 in LibretroHWRenderContext::ContextDestroy (this=0x555557a50190) at ../libretro/LibretroGraphicsContext.cpp:72
#8  0x00007fffe7ec7222 in context_destroy () at ../libretro/LibretroGraphicsContext.cpp:24
#9  0x0000555555660511 in video_driver_free_hw_context (p_rarch=0x555556588fa0 <rarch_st>) at retroarch.c:30537
#10 0x0000555555675e06 in core_unload_game (p_rarch=0x555556588fa0 <rarch_st>) at retroarch.c:39838
#11 0x0000555555638ed9 in command_event_deinit_core (p_rarch=0x555556588fa0 <rarch_st>, reinit=true) at retroarch.c:12211
#12 0x000055555563d4ae in command_event (cmd=CMD_EVENT_CORE_DEINIT, data=0x0) at retroarch.c:14347
#13 0x000055555566ee26 in rarch_ctl (state=RARCH_CTL_MAIN_DEINIT, data=0x0) at retroarch.c:36815
#14 0x000055555568e175 in content_load (info=0x7fffffff9a20, p_content=0x5555565a95f8 <rarch_st+132696>) at tasks/task_content.c:1470
#15 0x000055555568ed4f in task_push_start_dummy_core (content_info=0x7fffffff9a20) at tasks/task_content.c:1830
#16 0x000055555563c8b2 in command_event (cmd=CMD_EVENT_UNLOAD_CORE, data=0x0) at retroarch.c:13969
#17 0x00005555559a34bd in generic_action_ok_command (cmd=CMD_EVENT_UNLOAD_CORE) at menu/cbs/menu_cbs_ok.c:1823
#18 0x00005555559ab5f6 in action_ok_close_content (path=0x7fffffffcd98 "Close Content", label=0x7fffffffce97 "unload_core", type=151, idx=2, entry_idx=0) at menu/cbs/menu_cbs_ok.c:5085
#19 0x0000555555624022 in generic_menu_entry_action (userdata=0x55555747ac60, entry=0x7fffffffcd80, i=2, action=MENU_ACTION_OK) at retroarch.c:2573
#20 0x000055555593e019 in ozone_menu_entry_action (userdata=0x55555747ac60, entry=0x7fffffffcd80, i=2, action=MENU_ACTION_OK) at menu/drivers/ozone/ozone.c:640
#21 0x0000555555624ea6 in menu_entry_action (entry=0x7fffffffcd80, i=2, action=MENU_ACTION_OK) at retroarch.c:2853
#22 0x0000555555622d96 in generic_menu_iterate (p_rarch=0x555556588fa0 <rarch_st>, menu_st=0x5555565a35f0 <rarch_st+108112>, p_disp=0x5555565ab830 <rarch_st+141456>, p_anim=0x5555565a6c28 <rarch_st+121992>, 
    settings=0x7ffff11d7010, menu=0x55555746cc20, userdata=0x55555747ac60, action=MENU_ACTION_OK, current_time=9093315016) at retroarch.c:2155
#23 0x000055555562851c in menu_driver_iterate (p_rarch=0x555556588fa0 <rarch_st>, menu_st=0x5555565a35f0 <rarch_st+108112>, p_disp=0x5555565ab830 <rarch_st+141456>, p_anim=0x5555565a6c28 <rarch_st+121992>, 
    settings=0x7ffff11d7010, action=MENU_ACTION_OK, current_time=9093315016) at retroarch.c:4650
#24 0x00005555556723fb in runloop_check_state (p_rarch=0x555556588fa0 <rarch_st>, settings=0x7ffff11d7010, current_time=9093315016) at retroarch.c:38373
#25 0x0000555555674314 in runloop_iterate () at retroarch.c:39075
#26 0x000055555563fd84 in rarch_main (argc=1, argv=0x7fffffffde28, data=0x0) at retroarch.c:15708
#27 0x000055555582fc39 in main (argc=1, argv=0x7fffffffde28) at ui/drivers/ui_qt.cpp:4318

On Linux at least, this freeze is specific to glcore and does not occur on vulkan. It occurs only when closing content and loading the dummy core, not when closing retroarch fully with the core running. I pulled both a gdb backtrace and strace in case they help. Unlike some core freezes, this one stops strace dead with no further output whatsoever. @Jamiras's interpretation of the issue seems likely from my perspective:

It's most likely a deadlock between threads 1 and 15. Thread 1 is waiting for the emulator to finish processing frames:

ppsspp/libretro/libretro.cpp

Lines 578 to 580 in cbf2d3a

	// Need to keep eating frames to allow the EmuThread to exit correctly.
	while (ctx->ThreadFrame())
	continue;

and thread 15 "Emu" is waiting for the audio driver to have enough space to write more sound data (https://github.com/libretro/RetroArch/blob/master/audio/drivers/pulse.c#L266). If thread 15 doesn't unblock, thread 1 will wait indefinitely.

I think the libretro code handles audio pretty differently from our other ports, but maybe the issue is that it's trying to push audio after it's already supposed to have shutdown or something? Does it know at this point about shutdown?

I'd argue that libretro should probably insta-fail this API if you call it after shutdown rather than deadlocking, but I understand that libretro isn't designed for multithreaded programming or to handle programming design from the past few decades.

-[Unknown]

using vulkan for the driver solved the problem for me

Using Vulkan also fixed this for me