Is anyone able to get sound with no popping on a Nexus 7? I’m using the SNES core. I’ve searched the forums and the docs, so I’ve tried what I believe to be the things to try:
OS-reported refresh rate
Calibrated refresh rate
Manual forced refresh rate (tried 60 all the way down to 58 in increments)
No matter what I try I get the exact same amount of popping, which makes me wonder if my changes are actually taking effect on my hardware.
take the PCSX ReARMed core - if it has the same kind of audio pops - go to ‘Core Options’ in RGUI - and set Frameskip to 1.
If it is audio popless that way - it looks like I might have to introduce an ‘Auto Frameskip’ option for every core.
Trying ‘Theaded video’ might also help you - but video update won’t be as smooth as with it turned off.
Really - this is why RetroArch iOS rules in comparison to Android - you just don’t have this stupid problem - at all. You don’t need to resort to ‘frameskip’ to get good audio/video sync without audio pops or lagging graphics. With RetroArch iOS you don’t even have to think about this problem - because frameskip 0 will give you excellent results. And why? Because it is all totally native unmanaged code running - with a decent screen with a decent refresh rate - with an excellent low-latency audio API (CoreAudio) - without a shitty VM with a garbage collector ruining performance.
Main problem on Android is very bad audio latency + bad screens on top-tier Android devices with sub-60Hz refresh rates + a shitty Java VM with a garbage collector creating stalls that screws up audio/video sync. All of this translates into severe performance issues for applications that demand tight syncing (like emulators).
Another alternative to mitigate the problems would be - going to an AOSP ROM - this might cut off some of the Samsung bloat in the stock ROM. Or go with Cyanogenmod - I saw video latency being cut in half when going from stock ROM to Cyanogenmod 9.
take the PCSX ReARMed core - if it has the same kind of audio pops - go to ‘Core Options’ in RGUI - and set Frameskip to 1.
If it is audio popless that way - it looks like I might have to introduce an ‘Auto Frameskip’ option for every core.
Trying ‘Theaded video’ might also help you - but video update won’t be as smooth as with it turned off.
Really - this is why RetroArch iOS rules in comparison to Android - you just don’t have this stupid problem - at all. You don’t need to resort to ‘frameskip’ to get good audio/video sync without audio pops or lagging graphics. With RetroArch iOS you don’t even have to think about this problem - because frameskip 0 will give you excellent results. And why? Because it is all totally native unmanaged code running - with a decent screen with a decent refresh rate - with an excellent low-latency audio API (CoreAudio) - without a shitty VM with a garbage collector ruining performance.
Main problem on Android is very bad audio latency + bad screens on top-tier Android devices with sub-60Hz refresh rates + a shitty Java VM with a garbage collector creating stalls that screws up audio/video sync. All of this translates into severe performance issues for applications that demand tight syncing (like emulators).
Another alternative to mitigate the problems would be - going to an AOSP ROM - this might cut off some of the Samsung bloat in the stock ROM. Or go with Cyanogenmod - I saw video latency being cut in half when going from stock ROM to Cyanogenmod 9.[/quote]
I just tried the PCSX core with frameskip 1. No change. Also tried turning on the threaded video, no change. My Nexus 7 is running the stock Google-provided Android ROM, so I’m not suffering from Samsung bloatware or anything like that. The thing about Cyanogenmod does sound interesting though.
For comparison purposes I have tried a couple of other SNES emulators on the Play Store, and of the two, one in particular has good sound on my Nexus 7 - Snes9x EX+.
Thanks for the help and I will continue to assist with testing if other options become available.
take the PCSX ReARMed core - if it has the same kind of audio pops - go to ‘Core Options’ in RGUI - and set Frameskip to 1.
If it is audio popless that way - it looks like I might have to introduce an ‘Auto Frameskip’ option for every core.
Trying ‘Theaded video’ might also help you - but video update won’t be as smooth as with it turned off.
Really - this is why RetroArch iOS rules in comparison to Android - you just don’t have this stupid problem - at all. You don’t need to resort to ‘frameskip’ to get good audio/video sync without audio pops or lagging graphics. With RetroArch iOS you don’t even have to think about this problem - because frameskip 0 will give you excellent results. And why? Because it is all totally native unmanaged code running - with a decent screen with a decent refresh rate - with an excellent low-latency audio API (CoreAudio) - without a shitty VM with a garbage collector ruining performance.
Main problem on Android is very bad audio latency + bad screens on top-tier Android devices with sub-60Hz refresh rates + a shitty Java VM with a garbage collector creating stalls that screws up audio/video sync. All of this translates into severe performance issues for applications that demand tight syncing (like emulators).
Another alternative to mitigate the problems would be - going to an AOSP ROM - this might cut off some of the Samsung bloat in the stock ROM. Or go with Cyanogenmod - I saw video latency being cut in half when going from stock ROM to Cyanogenmod 9.[/quote]
I just tried the PCSX core with frameskip 1. No change. Also tried turning on the threaded video, no change. My Nexus 7 is running the stock Google-provided Android ROM, so I’m not suffering from Samsung bloatware or anything like that. The thing about Cyanogenmod does sound interesting though.
For comparison purposes I have tried a couple of other SNES emulators on the Play Store, and of the two, one in particular has good sound on my Nexus 7 - Snes9x EX+.
Thanks for the help and I will continue to assist with testing if other options become available.[/quote]
Android is still the main problem - it is not RetroArch and it is not our cores either. Android being dogshit is what it is. It can’t deliver on frameskip 0 - it can’t deliver on much of anything really.
Blackberry doesn’t suffer from any of these issues, neither does iOS. It is Android’s fault and therefore Google’s fault.
I will continue to hate on Google and their shit OS as long as they don’t fix their horrible garbage OS and the numerous issues it has (shitty Java VM with a garbage collector that kills performance - totally dogshit audio driver latency - totally arbitrary video blitting speeds - ranging from ‘meh OK’ to ‘absolutely awful’ - totally awful input driver latency - devices with sub-60Hz screens - no formal standards imposed on vendors for anything - total market fragmentation - totally inadequate scheduling - and on and on and on). Frankly this company is taking us all for a ride with this broken crap and it’s unfortunate to see so many people flushing good money down the toilet for devices that run this absolutely terrible OS. Never have I held this much animosity towards an OS since the Windows 9x days when Direct X 3 would crash a game every 5 minutes or so - it is like that except instead of it crashing every 5 minutes it stalls and lags like mad every 5 minutes.
If it were up to me at this point I’d just consider euthanizing RetroArch Android since it is just giving RetroArch a bad name and giving people the FUBARed impression that frameskipping and audio buffering disasters like Broglia’s are actually better (when RetroArch iOS actually totally wipes the floor and back with him - like it should on any DECENT OS) - but that would disappoint a lot of people and there are some who say everything is working right for them so I guess it is doing some good after all on some devices. But that still doesn’t discount the fact that this Android port is a huge albatross around our neck because it’s the only one where we absolutely CANNOT guarantee any kind of stable runtime performance state on because the OS is just crap, non-scaleable, and not performance-oriented.
It is so sad - it is the only platform where we are ALLOWED to be on the official market store - and to have that port be such a ‘Russian roulette’ in terms of ‘will it run well?’ leaves a lingering and depressing aftertaste in my mouth. What is even worse is that there is absolutely nothing we can do about it without compromising on the things we care most about - namely, zero-frameskip gameplay. For this, I absolutely hate Google and (in specific) the Android engineering team behind it. What infuriates me the most about the latter ‘engineers’ is that they have their heads stuck up their arses and think everything is ‘just fine’ - and nobody in the development community has the guts or the balls to call them on it - namely, that what they have so far in Android 4.2.2 is just totally pathetic compared to iOS 6 - it is not even at feature parity - it is lightyears behind Apple.
And you DO NOT solve this problem by just throwing better hardware at it, Ms. Hackborn - you can throw a Cortex A25 at this Android OS of yours with eight cores and the same problems would persist. You SOLVE IT by getting rid of the crapware Java VM, going back to the drawing board and GUTTING EVERYTHING. Get the inversion process right - native code (C/C++) up front and your ‘managed code’ in a jail - THAT is how you design an OS. Not the other way around. Do you see Apple doing this, Ms. Hackborn? No. Do you see Blackberry doing it like this? No. Do you see Microsoft doing it like this? No. And why is that? Because this is ‘doing it wrong’. This smacks of a feature phone reject from the word go (not surprising that Android was just ‘bought’ from a startup that pitched a J2ME-style OS for digital cameras then - it really IS a remnant of the feature phone era).
If only we could have something as solid as iOS be open source like Android. Hell, I’d take anything at this point without some managed crapware VM.
Well there you go - Android land is just plain unpredictable and total russian roulette.
Really I come from a console background where I like having the guarantee that a runtime performance state is always fixed - on Android it can be all over the map even on highend phones/tablets.
Oh well - perhaps AndresSM can help troubleshoot your specific problems on the Nexus 7 - I should probably butt out of this conversatíon for now.
Unfortunately google fucked up big time with 4.2.2 and I mean fucked up big.
Their UI framework has a memory leak which is causing a lot of issues. People should downgrade to see more stable performance. Cm 10 has fixed the leak and so have several other custom roms. (I have a good old google nexus) if you have root access and have the ability to flash a rom, flash a good stable one and not any beta crap. It will do wonders with the emulation. For any of those who use a gnexus I suggest you use rasbean vanella to use retroarch with. (From personal experience, pick the one that you find that works best for you)
Just plain insanity really. Just one screwup after another. It’s becoming one big moving target of one big gaping bug being added ontop of another big bug in the subsequent update which will then have to be rectified in a future update.
I have to wonder where all the developers are that are giving Google hell for this crap. Why do they all remain silent? Why is Google permitted to make so many mistakes yet they are on Apple’s ass for every little issue (when Android so far can only DREAM of being as stable, being as performant as iOS)? Because it’s not just this issue - it’s been a big colossal screwup for nearly EVERY point release so far. Even open source projects run by bedroom coders don’t usually have such large gaping holes like this.
You really have to wonder what kind of shit for brains are working at the Android engineering department. It has been a consistent pattern of them breaking stuff in their toolchain and other mission-critical things on a per-version basis. Why oh why does this multibillion dollar company let one of their biggest projects be run by such woefully incompetent engineers?
You mean disregarding the ANR reports I’m getting when people try to use two or more Bluetooth gamepads? Yeah, it looks like a total lost cause to try to ‘fix that’.
I recently upgraded to the 2013 Nexus 7. This has solved the issue. Audio playback in Retroarch is flawless. A couple of notes:
With the 2012 model I experienced some audio choppiness/popping while using an Android music player and switching apps quickly. A friend of mine was able to reproduce the same behavior on another 2012 Nexus 7. Maybe the older model has inherent audio playback issues?
With the 2012 model my OS-reported refresh rate was 59.XXXXXXXXXXXXXX (long series of decimals). With the 2013 model my OS-reported refresh rate is 60.0Hz.
I also haven’t experienced any audio popping with the SNES9x-Next core on my 2012 Nexus 7 (using OS reported refresh rate).
I do get audio crackling with some games in the PCSX-reARMed core (fixed by using the threaded video driver), but other than that RetroArch has been pretty much flawless on this thing for me.
OK, so having threaded video be enabled by default is a much more sane ‘default’ choice than just letting people ‘detect’ their refreshrate, right? That’s certainly good to hear since that is the strategy I went for with this release.
BTW - just wondering - are you guys able to tell perceivable differences between threaded video and non-threaded video? If not, that is good news to us as well - means we might finally have a sane default option that could work well on the majority of Android devices.
I’m the OP and wanted to provide an update. I wasn’t able to get good sound on the 2012 model with the threaded driver.[/quote]
Sorry man just noticed you were the OP.
I had audio poping on my 2012 nexus 7 running rasbeanjelly rom no matter how much i tried to calibrate refresh rate. May have been the rom I was using. Updated to stock 4.3 installed r18 and decided to try with threaded video driver. Have not heard a pop since. Video really smooth too.
Not noticing much difference between threaded and non threaded except not hearing any poping audio with threaded. Could be different for others running different custom roms and stuff ?
OK, guess for the next versions we’ll just enable it by default without creating a popup and for the diehards - they can try to get static syncing working by their own.
That way we appeal both to power users and to the guys who just want to get things done with minimal fuss.
Also, I’m cleaning up the Android UI now (somewhat). I believe we maybe misinterpreted the complaints about the UI ‘sucking’ and maybe dismissed some valid complaints in the process. I think there should be a way to easily rectify some of these problems that people are having with it.