PCSX framerate on Nexus 7

I downloaded retroarch on my nexus 7 the other day and I’m loving it so far. It’s an excellent project and I’m glad to see it getting some recognition. I have had a couple of problems with it I can’t seem to solve, though. The main one is that when I try to boot up a PS1 rom on PCSX-rearmed I get terrible framerate. Maybe I just missed something but it seems like the Nexus 7 should be powerful enough to emulate the PS1 especially with rearmed. I’ve tried several different extensions to see if it made any difference including .bin, .img, .cue, and .iso. All of them have the same problem, though. I’ve tested them out with PCSX-relaoded on my computer and they work fine there so I don’t think it’s a problem of them being broken or corrupted. I also tried adding in the .bin files to the same directory as the roms just in case but no dice. Finally I tried finagling with the graphics settings and forcing 59.95 Hz refresh rate but no luck there either. Anything I’m doing wrong here? Do I just need to wait for an updated build? Thanks in advance!

Device: Nexus 7, 32-gig Android version: 4.2.1 Build number: JOP40D Retroarch version: 0.9.8.1 Extensions used: .bin, .cue, .iso, .img Games tested: Azure Dreams, Harvest Moon: Back to Nature PS1 binary files present in the same directory as the roms.

The .bin files in the same directory as the roms? What do you mean? A proper dump of a PS1 game always has two or more files (bin+cue, mdf+mds, etc), and they need to be in the same directory with matching file names.

Ah, is that so? I hadn’t realized. Well, there’s both a .cue, .img, .ccd and .sub for azure dreams, but only the cue and img show up in the emulator. Harvest Moon, however, is just an iso.

As for the bins in the same directory I’m talking about the PS1 binaries, the SCPH1001.BIN and what-not. PCSX-rearmed has it’s own binaries but the cores guide said it recommended to put the actual binaries in the same folder as the roms if there were issues, so I did.

I’m pretty sure your Nexus 7 is another one of these devices where the vendor skimped some corners and put in a screen with a less-than-stellar screen refresh rate. To make matters worse, just like Samsung with Galaxy S3, they probably lied about it by reporting screen refresh rate to Android to be something it’s not (ie. Samsung reports to the Android OS that the Galaxy S3 has a screen refreshrate of 60Hz, but that’s not true).

Therefore, if you have ‘Sync refreshrate to screen’ turned on, and IF your vendor did not attempt to report an honest ‘refresh rate’ measurement, then you will get broken performance. What you should do instead on such devices is to disable ‘Sync refreshrate to screen’ and to manually set ‘Locked refresh rate (Hz)’ - start with 59.95 and then go lower and lower until you hit the sweet spot.

For instance - B6S/quepaso was able to get perfect sound and video on his Galaxy S3 by setting ‘Locked refreshrate (Hz)’ to 59.50. Your mileage may vary on your Nexus 7.

Also - the new version (RetroArch Android 0.9.8.3) will come with a built-in help system that explains all this and more.

Thanks for the help!

I’d actually tried setting it to 59.95 hz before and it didn’t fix anything so I tried fiddling with it. Tried .05 decrements between 60 and 59, but no luck. For good measure I tried .5 decrements between 59 and 50 and even some lower and higher values like 30, 40, 80, 100 just to see what would happen. Still no change at all, though.

It’s completely possible that the refresh rate isn’t set properly but everywhere I go seems to say the Nexus 7 has an ‘impeccable refresh rate’ without listing an actual number. Couldn’t find one on the technical specifications on Wikipedia either (though I realize that’s not the be all end all). So I’m not entirely sure what the correct refresh rate should be (or even what the supposed refresh rate is). Is there some way I can try to find this out or should I just keep fiddling with the values? If I should keep fiddling is there some realistic range I should be looking between? Try smaller increments between 59 and 60? Sorry, I’m not really familiar with the tech.

That being said I’m not sure the refresh rate’s the issue. There’s not a desynch between the sound and video if that makes any difference. I can also run SNES and Gambatte without any framerate issues if that makes any difference. They both lag. I also tried running the roms I have under psx4droid but all I could get out of that was music with no picture. Music ran at full speed though. Sorry for the pain, but thanks again for helping.

For starters, you can look at what your device reports to the OS (as it’s screen’s refreshrate) -

in RetroArch, bring up the popup menu in the main menu and select ‘Report Refreshrate’.

That is the official ‘screen refreshrate’ value that the device reports to the OS. However, this might well be complete nonsense - manufacturers can fill in here whatever they want and most of the time they’re not even sure themselves what to fill in. Samsung got it right once with the Note 2 by truthfully filling in ‘58Hz’ into that box there - but for the Nexus devices I guess they’re back to ‘cheating’ at it again.

And yes, keep going lower with the refreshrate - I"m sure you just have not tried fiddling around with it long enough.

It could very well be that your screen is 58Hz or 57Hz and therefore the refresh rate of the app should be forcibly set to that to get any decent audio/video. This has happened before with the Note 2 (with its 58Hz screen) so it’s a possibility.

As for why this doesn’t happen on other emus? Who knows - Broglia at least seems to leave auto frameskip on by default so no wonder this isn’t apparent to you there - I suspect other emus don’t really take frameskip 0 and static synchronization too seriously either. If I can’t get a game to play at 60fps with frameskip 0 then it’s really not worth playing for me. That and frameskip would be just horrendous to rely on by itself.

If it helps explain anything, our approach to static synchronization is a bit like Higan/bsnes’ except for the fact that we have dynamic rate control.

Hopefully we can find some way to do automatic refresh rate measurement - but so far it’s not looking too good.