Speed problems with latest RetroArch Android builds

system · 15 January 2017 03:28

Greetings everyone ! And congratulations to the RetroArch and libretro team,your software seems pretty good !

That said, I have been trying for quite a while to get RetroArch Android working on my Lenovo IdeaPad A107. It is a rather low-specced device for RetroArch, from what I gathered by reading (it has a 1GHz ARM Cortex-A8 based SoC, exact model is OMAP 3622, with 512MB of RAM), but I was surprised that it could not get to run even the FCEUmm core, or the Gambatte one at fullspeed.

The thing that startled (and still startles) me is that, it does not even matter what refresh rate I choose. No matter what, the core (any core in fact) will run the game at approximately 50% to 60% of fullspeed. That estimate is based on music bpm differences between the soundtrack of the game, and the emulated system’s sound.

So I started investigating, and discovered that for some reason, in RetroArch, and only in RetroArch, the sound card displays erratic opening and suspending behavior; the sound card is always trying to go to suspend for some reason, to be reawakened as the frame is displayed. It seems odd to me that only RetroArch makes the sound subsystem display such an erratic behavior, and based on the times for reawakening the sound card taking about 30ms, it would explain the 50% emulation speed. Moreover, by looking at CPU usage during the execution of the FCEUmm core, I was able to see that the average CPU usage is approximately 25-30%, so the CPU should be able to run that core at fullspeed.

It is possible that RetroArch could simply be exposing a bug in the soundcard driver with it’s usage pattern, but no other emulator, or sound based software displays that problem.

To help in the process of investigating, I am posting the partial contents (private info removed) of an adb logcat session as the emulation was going with the FCEUmm core.

– Extract of the ALSA erratic behavior log messages:


D/Omap3ALSA( 1067): open called for devices 00000002 in mode 0 channels 00000000...
I/Omap3ALSA( 1067): Initialized ALSA PLAYBACK device default
E/AudioHardwareALSA( 1067): RE-OPEN AFTER STANDBY:: took 29 msecs
D/Omap3ALSA( 1067): open called for devices 00000002 in mode 0 channels 00000000...
I/Omap3ALSA( 1067): Initialized ALSA PLAYBACK device default
E/AudioHardwareALSA( 1067): RE-OPEN AFTER STANDBY:: took 31 msecs
D/Omap3ALSA( 1067): open called for devices 00000002 in mode 0 channels 00000000...
I/Omap3ALSA( 1067): Initialized ALSA PLAYBACK device default
E/AudioHardwareALSA( 1067): RE-OPEN AFTER STANDBY:: took 32 msecs
D/Omap3ALSA( 1067): open called for devices 00000002 in mode 0 channels 00000000...
I/Omap3ALSA( 1067): Initialized ALSA PLAYBACK device default
E/AudioHardwareALSA( 1067): RE-OPEN AFTER STANDBY:: took 31 msecs
D/Omap3ALSA( 1067): open called for devices 00000002 in mode 0 channels 00000000...
I/Omap3ALSA( 1067): Initialized ALSA PLAYBACK device default

As one can see, it seems like the soundcard is going to standby mode all the time. The major part of the 200kb log is messages similar to these.

– The log messages emitted by RetroArch as the core shut down:


I/RetroArch: (23184): device name: mg-capacitive
I/RetroArch: (23184): Deinitializing RetroArch...
I/RetroArch: (23184): Saving config at path: "/data/data/org.retroarch/cache/retroarch.cfg"
I/RetroArch: (23184): Saving regular SRAM.
I/RetroArch: (23184): SRM: *******************************FILTERED**************************
I/RetroArch: (23184): RTC: *******************************FILTERED**************************
D/dalvikvm( 1620): GC_CONCURRENT freed 588K, 57% free 3215K/7367K, external 1625K/2137K, paused 11ms+3ms
I/RetroArch: (23184): Saved successfully to "*******************************FILTERED**************************".
I/RetroArch: (23184): Average audio buffer saturation: 12.49 %, standard deviation (percentage points): 7.22 %.
I/RetroArch: (23184): Amount of time spent close to underrun: 99.97 %. Close to blocking: 0.00 %.
I/RetroArch: (23184): gfx_ctx_destroy().
I/RetroArch: (23184): Average monitor Hz: 33.553669 Hz. (45.368 % frame time deviation, based on 2048 last samples).
I/RetroArch: (23184): android_app_destroy!

I hope this information helps in finding what the issue is and from what software component it comes from ! Might be my device too, so I’ll investigate more on that matter.

Finally, I end my post on a question: in my quest for achieving fullspeed emulation with RetroArch, I have looked around the options for an FPS counter of some kind. Is there one in RetroArch, and if yes, how can I activate it ?

I thank you in advance for your answers, and if you need more information, feel free to ask ! I’ll even install the Android SDK and NDK on my computer if I need to !

system · 15 January 2017 04:25

Could be some stupid power management policy on your specific device that tries to constantly turn off the sound device at the most opportunily wrong times. We don’t even have any kind of direct access over audio other than going through OpenSL which is just a wrapper around AudioFlinger anyway. So we merely ‘implement’ OpenSL and that’s it. Only thing we can do from there is hope for the best - which on Android it seems is foolhardy.

Or it could be just a shit OpenSL driver implementation from your vendor.

Also, that monitor Hz it reports at the end looks rather worrying - 33Hz? What kind of refresh rate is the screen of your Android device running at? It could be variably running at a lower refresh rate based on power management policies,.

Anyway, perhaps maister can hazard some more guesses.

system · 15 January 2017 04:26

Hi Squarepusher !

You mentioned power management policies as a possible cause. I had thought about it too. But it’s strange that it only happens in RetroArch. On the other hand, you mentionned OpenSL, which I had not took in consideration. RetroArch is probably the only application on my device that uses OpenSL.

As to the monitor refresh rate report, it is important to notice the 45% frame time deviation: either it’s a report that the emulation runs slowly, or the display runs at a variable refresh rate. Took a peek at the device’s kernel’s code, it’s most likely not the case.

I was wondering though, since my tablet is rooted, perhaps I can tweak the power policies. Which I’ll try ! But even changing low-level hardware policies with sysfs didn’t change much. On the other hand, maybe OpenSL sets this when it runs.

Still, one seriously odd thing is that even shutting down the sound in the settings does not seem to fix the problem. In any case, it’s hard to tell the emulation speed, for me, without sound. Oh delicious irony.

Anyway, I’m still open to help !