RetroArch Android - READ if you have crackling audio/bad video

RetroArch Android devices
#1

NOTE - BEFORE TRYING THIS - PLEASE CONFIRM THAT THE CORE YOU ARE RUNNING SHOULD BE RUNNING AT FULLSPEED ON YOUR DEVICE. YOU CAN FIND OUT THE SYSTEM REQUIREMENTS FOR EACH CORE IN THE RETROARCH ANDROID CORES MANUAL.

If you find that speed is not what it should be or that the audio is popping/crackling, chances are that the refresh rate of the screen is getting reported incorrectly.

Unfortunately there is little we can do about this - some devicesreport nonsense refresh rates to the Android OS (such as the Xperia Play, or the Samsung Galaxy S3).

However, like the input autodetection, this is something that the users can help us out with. Even though these devices report a nonsense refreshrate, there is something that can be done about it -

  1. Go to RetroArch Settings, go to Video Settings.
  2. Turn off ‘Sync refreshrate to screen’.
  3. Press ‘Forced refreshrate (Hz)’ and set up a manual refresh rate. Start with 59.95 (which should be the default). If it still audio crackles with that value, lower the value by 0.01. Try the game again. If it audio crackes again, lower the value even more. Keep doing this until you finally find that video/audio are perfect.

Later on, there is going to be a way to report the refresh rate that you have found to work well on your device by e-mail so that we can add a ‘hack’ to RetroArch so that it will automatically use a ‘sane’ refreshrate instead of the one the device reports (erroneously). This will mean a lot of extra manual work for us but unfortunately on Android this seems to be the only way we can fix this issue.

if you find a refresh rate that works well for your particular device, let us know here. We’re going to have to find a way to ‘detect’ your device at startup and add the ‘ideal refresh rate’ to the ‘Sync refreshrate to screen’ autodetection list - so that in the future you will not have to input a manual refresh rate like this again.

9 Likes
#2

Tried numbers from 58.95 to 60.00 with 0.01 incrementation on my xperia play on gambatte core without a good result on the sound crackling. Edit 57.95 to 60.

#3

You have turned off “Sync refreshrate to Screen”, right? You might have to go even lower than 58.95.

Alternatively, try to go up from 59.95 in 0.01 increments if going lower than - say - 57/56/55Hz doesn’t work.

Also, turning off vsync might help. I always have Vsync disabled on my tablet - it gives me better performance and I’m not really able to notice any tearing on this screen anyway as a result of Vsync being off.

1 Like
#4

Yes i had unchecked vsync and sync refresh to screen, will try to go lower then.

1 Like
#5

Going in steps of 0.001 is not needed. 0.01 steps should be good enough. Steps of 0.001 should only be used for very fine tuning. The lower bound of refresh rates appears to be roughly 58 Hz. It’s probably a good idea to try a very low Hz value first to ensure that it’s really too low. (If refresh rate is too low, you’ll notice stuttery video, but good audio).

2 Likes
#6

Problem is i tried some values like 30.00 or 120.00 without noticing changes in video and small changes in crackling sound… Maybe should i reinstall the apk?

1 Like
#7

Problem is i tried some values like 30.00 or 120.00 without noticing changes in video and small changes in crackling sound… Maybe should i reinstall the apk?[/quote]

Um, how would you expect a 30Hz or 120Hz refreshrate to ever work fine? Just saying.

Anyway, for the next release (r11 - 0.9.8.3) - we have added a ‘Refresh Rate Calibration’ option - this should be much easier to use.

#8

Yeap, but a noob has to try… And as i had frustration not seeing results i tried to see if there was a visible difference between 2 very different framerates… i guess i will wait next update lol…

#9

Problem is i tried some values like 30.00 or 120.00 without noticing changes in video and small changes in crackling sound… Maybe should i reinstall the apk?[/quote]

Um, how would you expect a 30Hz or 120Hz refreshrate to ever work fine? Just saying.[/quote] Well, Maister says setting a low refresh rate should result in stuttery video, yet it doesn’t seem to change it at all, at least for me (running a Nexus 7). 15 all the way to 120 don’t appear to have any impact on either video or sound with “Sync refreshrate to screen” unchecked, and Vsync either on or off. It’s like the setting is being bypassed/disregarded and is running at 59.95 regardless.

For what it’s worth, Gambatte is the one giving me trouble as well.

#10

If the configured frame rate is very different from game FPS, RetroArch will give up trying to match the rates (because it’s not possible without detuning the music really bad.) If they differ with more than 4%, it’ll give up, and changing refresh rate further won’t change anything. Usually you notice stuttering if you configure refresh rate say, 0.5 FPS too low. It depends …

#11

Anyway, wait until the new version (r11) arrives (which won’t take too long - possiby today or failing that tomorrow) - it will have a new feature called ‘calibrate refresh rate’ which should hopefully take away most of the complaints on this issue.

#12

I m pretty ashamed about how a noob i am, but i discovered today that having (e) roms played casi perfectly on snes9x, contrary to (u) roms, works better than changing frame rates…

#13

Well - they run at 50fps (50Hz) as opposed to 60fps (60Hz) for NTSC games.

Anyway, I’m going to release a new version now.

#14

Sadly, r11 crashes for me when I try to calibrate refresh rate. The device is Motorola Razr xt910.


02-12 10:28:00.760 10824 10849 W dalvikvm: threadid=13: thread exiting with uncaught exception (group=0x40aa6210)
02-12 10:28:00.768 10824 10849 E AndroidRuntime: FATAL EXCEPTION: GLThread 982
02-12 10:28:00.768 10824 10849 E AndroidRuntime: java.lang.RuntimeException: createContext failed: EGL_BAD_CONFIG
02-12 10:28:00.768 10824 10849 E AndroidRuntime:     at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1203)
02-12 10:28:00.768 10824 10849 E AndroidRuntime:     at android.opengl.GLSurfaceView$EglHelper.throwEglException(GLSurfaceView.java:1189)
02-12 10:28:00.768 10824 10849 E AndroidRuntime:     at android.opengl.GLSurfaceView$EglHelper.start(GLSurfaceView.java:1018)
02-12 10:28:00.768 10824 10849 E AndroidRuntime:     at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1387)
02-12 10:28:00.768 10824 10849 E AndroidRuntime:     at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1241)
02-12 10:28:00.768   346   693 W ActivityManager:   Force finishing activity org.retroarch/.browser.DisplayRefreshRateTest
02-12 10:28:00.799   346   693 W ActivityManager:   Force finishing activity org.retroarch/.browser.SettingsActivity
#15

This seems to work fine for me on a Nexus 7. It also confirms that the Nexus 7 was reporting its refresh rate correctly, which is nice to know. :slight_smile:

Gambatte still has popping audio, so I imagine at this point it’s either an issue with the core or Tegra 3 isn’t powerful enough.

#16

Is it only Gambatte or is it more cores? (and yes, VBA Next is a given - we know - you’ll need at least a phone with Wii/PS3/360 specs for that to run tolerably - and ironically in some cases these multi-core Android phones actually run worse than a Wii).

I dunno why Gambatte of all cores would be running ‘slow’ - it is well known as one of the fastest cores around. Perhaps those GBC BIOS color palettes really dragged performance down by a lot - I really should find a way to make that entire thing optional to begin with because I don’t like how eadmaster made that the default to begin with.

If PCSX ReARMed still has audio pops (one of the faster cores around) - then you should run calibration again - this time trying to hold your fingers on the screen at all times. Perhaps it gives a more accurate measurement then. If it doesn’t have popping audio, then disregard this.

#17

Is it only Gambatte or is it more cores? (and yes, VBA Next is a given - we know - you’ll need at least a phone with Wii/PS3/360 specs for that to run tolerably - and ironically in some cases these multi-core Android phones actually run worse than a Wii).

I dunno why Gambatte of all cores would be running ‘slow’ - it is well known as one of the fastest cores around. Perhaps those GBC BIOS color palettes really dragged performance down by a lot - I really should find a way to make that entire thing optional to begin with because I don’t like how eadmaster made that the default to begin with.

If PCSX ReARMed still has audio pops (one of the faster cores around) - then you should run calibration again - this time trying to hold your fingers on the screen at all times. Perhaps it gives a more accurate measurement then. If it doesn’t have popping audio, then disregard this.[/quote] VBA Next and Gambatte are the only ones with issues (and yeah, VBA’s always been a hog so I expected that). Gambatte runs at full speed and looks great, but the popping happens no matter what I do. PCSX also runs at full speed with no issues as far as I can tell. Mednafen PCE Fast doesn’t like loading a large chunk of my roms, but that’s unrelated to any of this and what it does load works perfectly.

As for the GBC palette being optional, that would be great. I’ve always thought most original Gameboy games looked weird with GBC colors since they weren’t designed with that in mind, and it frequently makes sprites stand out when they aren’t supposed to. I get why other people like it, but it’s never been my preference and I’ve always used monochrome whenever possible.

#18

OK, so overall the ‘Calibrate refresh rate’ option has been a success for your device? It’s better than before?

If so, that’s good to hear at least.

#19

Detected 48.longstringofnumbers hz for my S7300, games still pretty unplayable, with bad sound and nasty input lag. Will try manually setting 48 exactly and see if it helps, but I might just need to wait for JXD to let us run the screen at 60hz, if they do/can.

#20

There’s no reason for them to ‘underreport’ a screen’s refresh rate like that - there’s an almost 99% chance this is indeed a 50Hz / 48Hz screen.

That the screen sucks on this device is not RetroArch’s fault - 50Hz/48Hz in this day and age is pretty damn low. I think the chances are high that JXD just plain doesn’t care - they sell these things on the cheap, it’s a typical Hong Kong/China outfit so support isn’t exactly high on their agenda either - and chances are the current model will likely be retired a few months from now.

Things ‘might’ be more tolerable with auto frameskipping, but honestly, it’s still going to be pretty bad regardless of which emu you’re using. If JXD can’t get rid of it, I’d try to get rid of it and settle for something decent which you will know will have at least a 60Hz screen (or failing that, 59, or failing that, 58 like Note 2 - anything but this travesty of 50/48Hz).

I guess this is a good lesson for people - be wary of these Android devices you buy and check first if they meet the basic necessities required for retro gaming/emulation. Refresh rate of the screen in this case should be the first thing you should be concerned about - tech specs second - a nice ‘game controller’ embedded as part of the tablet the absolute last priority.

Sorry to say, but the people going ‘you get what you pay for’ are right in this instance - if you had went with a Nexus 7 you wouldn’t have had this problem right now. I know about impulse buy purchases though myself - I bought an el-cheapo Cortex A8 tablet as well - a similar piece of hunk - although it did at least have a 61Hz refresh rate screen.