So, I don’t know if this is an issue specific to my tablet only, the Android Lollipop OS itself, or if it’s just bad luck, but on the Snes9x 1.53 core, I noticed that a lot of games have audio stuttering, despite running full speed, at least, as far as I can tell. Games that use enhancement chips like the Super FX (Star Fox, Yoshi’s Island), the game had crackling audio and stuttering and I don’t know why, seeing as the K1 processor contains a 2.2 GHz quad core CPU, I can see my old Nexus 7 doing this, but a Shield K1? The funny thing is, the standalone Snes9x EX+ doesn’t have trouble running full speed, the problem is that too has audio buffering issues, no matter the setting, I tried to contact the author about this and received no reply. Am I so cursed as to never experience Snes emulation without having some kind of audio stutter/crackling issue? Are there settings I can adjust to change the buffer size and reduce the stutter in RA 1.3? Everything else works fine, I got the ROM directory, save directory, controls, etc all working 100% perfectly, everything but audio, there’s no reason for a powerful tablet like this to be experiencing these audio issues, what I can do is capture the video with the built in recording app and then upload the video with the framerate counter on if need be.
Maybe something to do with your screen refrest rate? See: http://libretro.com/forums/showthread.php?t=189 Also you could try other snes cores like catsfc or pocketsnes.
[QUOTE=talos9;33457]Maybe something to do with your screen refresh rate? See: http://libretro.com/forums/showthread.php?t=189 Also you could try other snes cores like catsfc or pocketsnes.[/QUOTE]
The problem with those two emulators is that they are based off of Snes9x 1.43, this is the version prior to the cycle-accurate Blargg S-SMP/SPC700 core. Meaning the audio emulation will be inaccurate and out of sync, affecting the audio in many games that require precise SPC700 timing (Square Enix games are infamous for having precise timing, if the audio core emulation is off, they sound horrible). Oddly enough, I don’t experience this audio stuttering in Snes9x EX+, but that too has its own set of issues as every now and then there is a skip in audio no matter the buffer size. I don’t know if it’s the fact that it’s on Android Lollipop 5.1.1 or not, either way, I can test those other cores, but the sound is gonna be a lot worse accuracy-wise. The refresh rate was set by default at an estimated 59.950 Hz and so I adjusted it to 60.000 Hz manually and set the audio buffer size to 128 and 144 ms respectively, affecting it marginally.
I don’t know what else to do, so right now I’ll be reporting this issue on GitHub as no other cores exhibit this issue; other cores tested were Nestopia UE, Genesis Plus GX and neither of them suffered the audio issues Snes9x 1.53 did. I suppose I can try Snes9x Next, but that’s for weaker devices like the Wii and Gamecube, and the like. Surely, it can’t be the tablet being weak since the K1 is one of the most powerful ARM processors on the market, so I don’t know what else to do short of reporting the issue on GIT.
Edit: I’ll try the steps to lowering the refresh rate as well
Video as well https://www.youtube.com/watch?v=xVE19JqCcJM
I get a lot of audiostuttering on my xperia z3c too. However, i feel it’s down to dropped frames.
Its horrible with mupenplus64, although that already had issues on 1.2.2. (somewhere along the line performance of mupen64 degraded a lot; using 1.0.0.2 core on 1.2.2 gives perfect performance). However I even got trouble with trying to run neo geo games like mslug without stuttering… Moved back to 1.0.0.2 (omg, the menu was soooo much cleaner, classic rgui FTW) but switched back to 1.2.2 because it supporrs the DS3 better.
Really hope RA can find back to its original clean and leanness. It just feels soooo bloated
I have very bad audio stutter on my Sony Xperia Z3 Compact aswell (Snapdragon 801/Adreno 330). It is especially bad with Mupen64 (load up Zelda OTT and all you hear is carckling), but, as a first, it also crackles in other cores. For example I have noticable crackling with FBA and Metal Slug. However, I believe it is actually down to Framedrops. The whole thing seems a lot more inefficient. I’m shocked even the K1 has problems to run it fluidly; what are they testing their builds on?..
Now, while Mupen64 core got way ineffecient over the course of several commits from 1.0.0.2 to now (heck, even on my Laptop it started to drop frames) I had no problems with Neo Geo on 1.2.2… In fact, back when I still had my HTC EVO3D and retroarch was still on 1.0.0.2, I could run both Neo Geo and N64 just fine with Retroarch…
I rolled back to 1.0.0.2, just for the kicks of it and it ran butterly smooth on my Xperia; but it had some problems with Dual Shock input mapping, so I’ll settle on 1.2.2. for now. Using the old Mupen64 core from 1.0.0.2 yields good results (near to no crackling and no frame-drops); so whatever.
I think the way 1.3 is going is the right one (scratch stuff that was unnecessary and make everything more lean and clean again (I was shocked how simple and straight to the point the old rgui in 1.0.0.2 was)… But until this whole package is ridded of all it’s regressions and performance sapping bloatedness, I guess I’ll just have to stick to 1.2.2 and some older cores.
Do you have any power saving settings on? My nook HD is much slower than the shield tablet but I have smooth audio on snes9x and mupen64plus
The funny thing is, the standalone Snes9x EX+ doesn’t have trouble running full speed, the problem is that too has audio buffering issues, no matter the setting, I
That uses frame skipping instead and big audio buffers. Frame skipping is something that has to be implemented on a core level, it is not something you can just add to the frontend.
Are there settings I can adjust to change the buffer size and reduce the stutter in RA 1.3?
Yes, increase audio latency. 64ms is clearly not running well on your Android device, try bumping it up to 96 or 128ms. Sucks that you have to do this but that is Android for you.
Also, if threaded video is already enabled and that is causing bad runtime performance, try non-threaded video and set it to the refresh rate of your screen.
Finally, some Android devices’ schedulers only run at their peak performance if some touch activity is going on. In that case ,leaving an overlay on that is continually being pressed could maybe help kick it always into high-performance gear. Sigh, there is no end to the disaster that is this platform.
Games that use enhancement chips like the Super FX (Star Fox, Yoshi’s Island), the game had crackling audio and stuttering and I don’t know why, seeing as the K1 processor contains a 2.2 GHz quad core CPU, I can see my old Nexus 7 doing this, but a Shield K1?
The hardware might be good, but the operating system is terrible (Android). As simple as that really. I think users don’t really want to hear the truth about this issue but it’s pretty much a fact that Android is going to be inferior to iOS or Windows Phone any day of the week when it comes to consistent runtime performance.
BTW, regular mainstream reviews on tech sites everywhere are slowly seeing the light and reporting on just how badly Android performs. This ranges from UI stuttering to games that run on top-of-the-line ARM hardware that nevertheless fall far short of their PS3/360 counterparts. The entire platform is simply a disaster. I feel bad that this is reflecting so badly on RetroArch since users automatically blame the myriad issues of this OS and blame it on the enduser app, and that there is nothing we can do about this save compromising in some horrible way and enabling auto frameskip.
[QUOTE=Dixxhead;33475]
I think the way 1.3 is going is the right one (scratch stuff that was unnecessary and make everything more lean and clean again (I was shocked how simple and straight to the point the old rgui in 1.0.0.2 was)… But until this whole package is ridded of all it’s regressions and performance sapping bloatedness, I guess I’ll just have to stick to 1.2.2 and some older cores.[/QUOTE]
These aren’t regressions, it’s simply that your Android device for whatever reason cannot cut it with RA’s default audio/video settings, hence you should try 96 or 128ms. Those are the first things you should try.
Speaking of regressions, Android is one big regression in and of itself. With every version they manage to fuck up something new again. It is truly a horrible platform to develop for and I think much lowlier of Google ever since I know they willingly put out an OS this shoddy onto the marketplace and just let developers ‘deal’ with the ensuing mess.
It’s sad too because there was a point in time where I thought Android could be something nice and positive. An open-source LInux-based mobile OS, what’s not to love right? Sadly it turned out to be more a Java2ME feature phone era relic where honestly it might as well be running a Windows kernel for all the difference the Linux kernel makes to the user experience.
[QUOTE=Twinaphex;33486]That uses frame skipping instead and big audio buffers. Frame skipping is something that has to be implemented on a core level, it is not something you can just add to the frontend.
Yes, increase audio latency. 64ms is clearly not running well on your Android device, try bumping it up to 96 or 128ms. Sucks that you have to do this but that is Android for you.
Also, if threaded video is already enabled and that is causing bad runtime performance, try non-threaded video and set it to the refresh rate of your screen.
Finally, some Android devices’ schedulers only run at their peak performance if some touch activity is going on. In that case ,leaving an overlay on that is continually being pressed could maybe help kick it always into high-performance gear. Sigh, there is no end to the disaster that is this platform.
The hardware might be good, but the operating system is terrible (Android). As simple as that really. I think users don’t really want to hear the truth about this issue but it’s pretty much a fact that Android is going to be inferior to iOS or Windows Phone any day of the week when it comes to consistent runtime performance.
BTW, regular mainstream reviews on tech sites everywhere are slowly seeing the light and reporting on just how badly Android performs. This ranges from UI stuttering to games that run on top-of-the-line ARM hardware that nevertheless fall far short of their PS3/360 counterparts. The entir e platform is simply a disaster. I feel bad that this is reflecting so badly on RetroArch since users automatically blame the myriad issues of this OS and blame it on the enduser app, and that there is nothing we can do about this save compromising in some horrible way and enabling auto frameskip.[/QUOTE]
So in essence, I’m s**t out of luck and I should just flat out give up if all else fails? Well, at least I’m not trying to run this app on my 2012 Nexus 7, now that would suffer a lot more for sure, that much I would know. Yes, the sync thread to video is enabled, I haven’t tested manually adjusting the refresh rate or forcing it to sync in that manner. That being said, I hope that I wasn’t trying to place the blame on the app, but rather on my own stupidity in not trying alternate methods of adjusting the settings, and for that I sincerely apologize 
That said, I have adjusted the audio buffer to beyond 64 ms, to 144 ms, and the funny thing is, other cores don’t seem to exhibit the same amount of audio stuttering (maybe I didn’t notice it as much, I don’t know, will retest today, thoroughly). I do thank you for your honesty however, as I was about to make a GitHub report, but I’m glad I stopped myself from doing that, it would’ve wasted both your and my time like no other. Anyways, there’s still hope yet, I’ll disable the threaded video and try the suggestions in that refresh rate thread posted above. Given that Android OS isn’t an ideal platform, are there measures being taken to squeeze out as much optimization as possible? And the reason I didn’t get a Windows based tablet, is because installing emulators is a pain in the arse as there’s not a dedicated app store, that and Microsoft isn’t too keen on installing emulators, so it’s not as user friendly as far as I know. That and the fact many emulator apps aren’t written with x86-64 in mind. Should I simply roll back to Android 1.2.2 or 1.0.0.2 in the mean time?
Does this mean that you guys are giving up Android development? Is there no hope?
I apologize for wasting your time with such a trivial thread -_-
Don’t beat yourself up over android’s shortcomings nintendonerd, and installing emulators on a win tablet isn’t as bad as one would think. While there are some emulators on the windows store (don’t know how well they perform because I don’t use em), retroarch and many standalone emulators run quite nice on my dv8p.
[QUOTE=nintendonerd1889;33503]So in essence, I’m s**t out of luck and I should just flat out give up if all else fails? Well, at least I’m not trying to run this app on my 2012 Nexus 7, now that would suffer a lot more for sure, that much I would know. Yes, the sync thread to video is enabled, I haven’t tested manually adjusting the refresh rate or forcing it to sync in that manner. That being said, I hope that I wasn’t trying to place the blame on the app, but rather on my own stupidity in not trying alternate methods of adjusting the settings, and for that I sincerely apologize That said, I have adjusted the audio buffer to beyond 64 ms, to 144 ms, and the funny thing is, other cores don’t seem to exhibit the same amount of audio stuttering (maybe I didn’t notice it as much, I don’t know, will retest today, thoroughly). I do thank you for your honesty however, as I was about to make a GitHub report, but I’m glad I stopped myself from doing that, it would’ve wasted both your and my time like no other. Anyways, there’s still hope yet, I’ll disable the threaded video and try the suggestions in that refresh rate thread posted above. Given that Android OS isn’t an ideal platform, are there measures being taken to squeeze out as much optimization as possible? And the reason I didn’t get a Windows based tablet, is because installing emulators is a pain in the arse as there’s not a dedicated app store, that and Microsoft isn’t too keen on installing emulators, so it’s not as user friendly as far as I know. That and the fact many emulator apps aren’t written with x86-64 in mind. Should I simply roll back to Android 1.2.2 or 1.0.0.2 in the mean time?
Does this mean that you guys are giving up Android development? Is there no hope?
I apologize for wasting your time with such a trivial thread -_-[/QUOTE]
No it’s still being worked at, but there are things that can be helped. I ran the same RetroArch build and Mupen 64 on Android 4.4 and it was faster than it is now on 5.1, always on the same device.
[QUOTE=Radius;33530]No it’s still being worked at, but there are things that can be helped. I ran the same RetroArch build and Mupen 64 on Android 4.4 and it was faster than it is now on 5.1, always on the same device.[/QUOTE]
I suspected as much, unfortunately, I know of no way to downgrade the Shield Tablet back to 4.4.4 KitKat, but I’m not surprised that OS is faster than 5.1.1 Lollipop. Good to know that measures are being taken to optimize speed even further as well as the quirks that degrade performance, and one thing is for sure, I’m sure as hell never going to Marshmallow, because it doesn’t sound that great. That being said, do you recommend I roll back to RA 1.2.2 or 1.0.0.2 in the mean time? I assume version 1.2.2 would at least support the Moga PRO that I have, correct? I want to be sure, and in the mean time, I’ll follow the suggestion of turning off sync thread to video and manually adjusting the refresh rate as per that thread.
I too am disappointed at Lollipop’s performance, my Shield has been rooted with a stock ROM of 5.1.1 or whatever Lollipop has, I’ve yet to find a 4.4.4 ROM, they have to exist somewhere and if I can do go to that, I would get much better performance. Damn you, Lollipop, you suck. To be honest, if I can’t get better performance or less stutter by adjusting the refresh rate…I might have to roll back, though that could break support for my MOGA pad.
While Android is definetly to blame (it’s super inefficient when it comes to running games), it is still a fact that I can run all cores relevant to me and stutter free with the 1.2.2.
So short answer for you Nintendonerd: Yes, downgrade Retroarch to 1.2.2.
While I undestand where Twinaphex is coming from, being frustrated first by android and then by the unhappy users, we have to acknowledge the probleme here, that 1.3 just runs way worse than 1.2. And it’s something you can’t really just overlook… As I said, stuttering Audio with every core I tried, even less taxing ones like FBA with Metal Slug…
And it is also very very clear, that Mupen64plus core has degraded in terms of Performance (and dare I say even featureset, seeing as no GPU Plugin but Glide works) over the course of several commits from 1.0.0.2 onward. As a matter of fact, I am now using 1.0.0.2 Mupen core on the 1.2.2 Retroarch and have no trouble , be it with framerates or audio stutters. It runs just as well as Mupen64 AE.
I’m sorry I can’t give any more specific info for devs, if there is any way to help you out with some more specific data, to get this great project back on track for android, I’d be more than happy to help.
To summarize: Device: Xperia Z3C FW: Android 5.1.1. Rooted RA 1.3 - Audio stutters in most cores I tried RA 1.2.2…- Menu very complicated, but great plug and play support for Gamepads. Most cores work fine, have to use old Mupen Core for N64 stutter free gameplay. RA 1.0.0.2- Lean and Clean Menu (shame the android gui got deprecated but rgui is fine for mobile really), Best performance, but some comp. issues with controllers.
I just use the most recent nightlies on my shield devices and I haven’t really noticed bad regressions but I just play SNES/Genesis/CPSx on my shields
So in essence, I try the old version first, okay, that I can do. At least, I’ll do that after I try the refresh rate adjustment method (overwriting it manually in .01 Hz increments). Then if all else fails, I’ll use 1.2.2, never mind that the GUI is that way, I’m used to it as I use the Wii version a lot.
[QUOTE=Dixxhead;33535]While Android is definetly to blame (it’s super inefficient when it comes to running games), it is still a fact that I can run all cores relevant to me and stutter free with the 1.2.2.
So short answer for you Nintendonerd: Yes, downgrade Retroarch to 1.2.2.
While I undestand where Twinaphex is coming from, being frustrated first by android and then by the unhappy users, we have to acknowledge the probleme here, that 1.3 just runs way worse than 1.2. And it’s something you can’t really just overlook… [/quote]
Not true. Prove it is. It would affect more platforms than just Android then. And it clearly doesn’t.
As I said, stuttering Audio with every core I tried, even less taxing ones like FBA with Metal Slug…
How come radius experiences no issues then? Did you try changing audio latency setting yet? Did you try all the other things we suggested? Or did you just draw this conclusion and you’re sticking to it?
You know how many variables are involved with performance on a random Android device? You cannot make such blanket statements like ‘this version runs way worse than version x’ on a platform like Android, the performance is determined by all sorts of external factors that have nothing to do with the runtime app in question.
And it is also very very clear, that Mupen64plus core has degraded in terms of Performance (and dare I say even featureset, seeing as no GPU Plugin but Glide works) over the course of several commits from 1.0.0.2 onward. As a matter of fact, I am now using 1.0.0.2 Mupen core on the 1.2.2 Retroarch and have no trouble , be it with framerates or audio stutters. It runs just as well as Mupen64 AE.
That is not our fault, that is because Mupen64plus mainline did many core refactorings that turned out to make things much slower, and we just backported them.
Anyway, I don’t see much point to sticking with upstream anymore as they seem to not have the dedication or willpower to really try to bring their emulator up to the level of PJ64, so I’m probably going to change it back to the way it was and get ourselves some performance back.
[QUOTE=Twinaphex;33546]Not true. Prove it is. It would affect more platforms than just Android then. And it clearly doesn’t.
How come radius experiences no issues then? Did you try changing audio latency setting yet? Did you try all the other things we suggested? Or did you just draw this conclusion and you’re sticking to it?
You know how many variables are involved with performance on a random Android device? You cannot make such blanket statements like ‘this version runs way worse than version x’ on a platform like Android, the performance is determined by all sorts of external factors that have nothing to do with the runtime app in question.
If 1.3 doesn’t run worse than 1.2.2, then what is the actual core of the problem, especially since the K1 tablet has a 192 kepler-core GPU and a 2.3 GHz quad core CPU with 2 GB of RAM? Surely, those would be powerful enough to run RA without having to worry about stuttering, right?
That is not our fault, that is because Mupen64plus mainline did many core refactorings that turned out to make things much slower, and we just backported them.
Anyway, I don’t see much point to sticking with upstream anymore as they seem to not have the dedication or willpower to really try to bring their emulator up to the level of PJ64, so I’m probably going to change it back to the way it was and get ourselves some performance back.[/QUOTE]
First I try manually adjusting the refresh rate, disabling the sync video thread, and failing that, roll back to 1.2.2 as a last resort? So far, I can’t find any stock ROM for Android 4.4.4 on the K1 tablet, they exist I’m sure, so I’m stuck with Android 5.1.1.
Sorry, I’m just curious is all, because given the specs of the K1, I shouldn’t be having these issues, this is one of the most powerful gaming tablets on the market. Am I shit out of luck, especially given the fact Android 5.x has been suffering from performance degradation? Should I just just give up trying to get the most out of RA?
[QUOTE=nintendonerd1889;33548]First I try manually adjusting the refresh rate, disabling the sync video thread, and failing that, roll back to 1.2.2 as a last resort? So far, I can’t find any stock ROM for Android 4.4.4 on the K1 tablet, they exist I’m sure, so I’m stuck with Android 5.1.1.
Sorry, I’m just curious is all, because given the specs of the K1, I shouldn’t be having these issues, this is one of the most powerful gaming tablets on the market. Am I shit out of luck, especially given the fact Android 5.x has been suffering from performance degradation? Should I just just give up trying to get the most out of RA?[/QUOTE]
Have you tried changing the settings like I suggested back on the previous page? Somehow some of these settings should influence your audio/video sync, there is no way it can be left unaffected.
Whoops, yeah, so a couple of things, one, the Snes9x Next core (based off of 1.52 as far as I know), seems to run somewhat better and has less stuttering, not as accurate as 1.53, but I can’t really tell any diff in terms of which is more accurate. What confuses me is that the estimated refresh rate is constantly fluctuating, it never stays constant as it estimates the value. Threaded video has been disabled, isn’t there an app that can test the true refresh rate of the screen, and then I enter that instead of letting RA guess the accurate value? I disabled the overlay first time I ran this app, it crowds the screen since I use a controller (way easier to navigate and play), And as a last test, could the custom viewport resolution being 1080 impact performance at all? Mostly curious.
To sum up:
Audio buffer is set to 128 ms Refresh rate: set to the one that it detects in the emulator 59.784 Hz Core: Snes9x 1.53 (testing this currently) Vsync: Disabled
The games where it’s most noticeable are games with enhancement chips; I’ll record another video as a test. But the Snes9x Next core did yield less stuttering, oddly enough.
Edit: And dammit all to hell the crackling doesn’t go away with the Hz this high, like…at all, this is really starting to piss me off a lot. I feel cursed, I feel like I made a huge mistake in many ways…dammit… OpenGL app reported 60 fps flat, which is different.
I made a mistake in spending money on there as there is absolutely no open in seeing performance boost, that, and I can’t install 1.2.2, so… Oh and to add insult to injury, I can’t seem to install RetroArch 1.2.2 from the download server, it tells me “App did not install” using ES File Explorer, and this device is rooted and unlocked, so, IDFK. -_-
So…yeah, I’m stuck, SOL, unable to install older versions. Could it be that it’s detecting the 1.3.0 version and refuses to install via ES explorer?
Not sure what your issue is, I run with vsync on and 64ms on an NVdia shield portable that’s way slower than the k1 and I don’t get stuttering, also I’m using mainline SNES9x, not NEXT. Mupen is borked on my device since the lollipop update but other than that I have no issues.