I have, to obscene levels in fact, often around 224 to 256 ms. One shouldn’t have to go that high -_- Either that or I’m forever doomed to never play this on any Android device ever again, powerful or not. Guess my only hope is the fabled Wii U port now that the console has a full blown PPC kernel exploit (which was leaked a couple of weeks ago). Yeah, like that’s gonna happen.
My 2015 moto e has this issue too the audio plays fine and the game is at full speed but it makes ticking noises.
Have you guys tried the other audio driver?
What other audio driver? I thought Android only used one?
Yes I tried Rsound and it wouldn’t play any audio.
What other audio driver? I thought Android only used one?
You mean rsound? Yeah, that had no audio for me. Also, I’m getting dropped frames on Star Fox, this freakin sucks ass.
This is the part of the superfx driver for snes9x next
void S9xSuperFXExec (void) { bool8 address_valid; uint16 GSUStatus; /* EMULATE FX CHIP*/ /* Execute until the next stop instruction*/ uint32 nInstructions = (Memory.FillRAM[0x3000 + GSU_CLSR] & 1) ? SuperFX.speedPerLine * 2 : SuperFX.speedPerLine;
/* Read registers and initialize GSU session*/
fx_readRegisterSpace();
/* Check if we start inside the cache*/
if (GSU.bCacheActive && R15 >= GSU.vCacheBaseReg && R15 < (GSU.vCacheBaseReg + 512))
address_valid = TRUE;
else /* Check if the start address is valid*/ address_valid = fx_checkStartAddress();
if (address_valid)
{
/* Execute GSU session*/
CF(IRQ);
/* GSU executions functions*/
GSU.vCounter = nInstructions;
READR14;
while (TF(G) && (GSU.vCounter-- > 0))
{
/* Execute instruction from the pipe, and fetch next byte to the pipe*/
uint32 vOpcode = (uint32) PIPE;
FETCHPIPE;
(*fx_OpcodeTable[(GSU.vStatusReg & 0x300) | vOpcode])();
}
}
else
{
CF(G);
}
/* Store GSU registers*/
fx_writeRegisterSpace();
/* EOF EMULATE FX CHIP*/
GSUStatus = Memory.FillRAM[0x3000 + GSU_SFR] | (Memory.FillRAM[0x3000 + GSU_SFR + 1] << 8);
if ((GSUStatus & (FLG_G | FLG_IRQ)) == FLG_IRQ)
{
S9X_SET_IRQ(GSU_IRQ_SOURCE);
}
}
The line /* Execute until the next stop instruction*/ means there is no timing and the while loop looks like it is blocking.(ie if there are enough super fx instructions it wont finish in time to make sound samples so the speaker stops and restarts abruptly causing the popping)
With infinte speed it would finish instantly and not cause a problem but any less and there will be popping(Even if it is so short that you cant hear it.) since it is waiting to generate samples.
So faster = better but this is a bug.
Also when I played yoshis island it acted weird(popping) when there where big sprites on screen but fine otherwise.(Yoshis island uses the super fx as well but for scaling instead of 3d)
So where does this leave us? I’m not exactly a programmer and have no idea on how/if this issue can even be resolved. If we have to make a hack, so be it, as long as it doesn’t interfere with how games behave. I was running Star Fox, tweaking various settings, having as high as 256 ms of audio latency, no threaded video, no audio sync, and the damn game popped more than a bag of Jiffy Pop. So, yeah, I’m on the verge of flat out giving up, the devs can’t reproduce it, and I just don’t know. If this code can show how it works, and it does, maybe this can help the devs use this as a solution? There is no excuse for a Tegra K1 to have issues with this emulator.
I believe Yoshi’s Island used the second revision of the Super FX chip, the GSU-2 I believe. sigh
Can you please list all of the values under Audio config.
My nexus 7(that works): Audio latency = 128 Block Frames = 512 Audio output rate = 44100
My moto e2(that dosent work): Audio latency = 120 Block Frames = 1920 Audio output rate = 48000
[QUOTE=guicrith;39028]Can you please list all of the values under Audio config.
My nexus 7(that works): Audio latency = 128 Block Frames = 512 Audio output rate = 44100
My moto e2(that dosent work): Audio latency = 120 Block Frames = 1920 Audio output rate = 48000[/QUOTE]
How do you change the output to 44.1 to 48 kHz? I take it I have to mod the config file on the SD/internal storage? I can’t choose it in the emulator itself. The other settings, yes, I can change easily. Could it be because the newer tablets are using Lollipop? Stupid Google, always screwing up their OSes. I thought the block was set at 512 by default, 128 ms crackles to high heaven for me, so…what do I test? This is pissing me off -_-
I have tried everything under the sun, and still the freaking audio crackles. I can’t use the other sound driver, Rsound, because it doesn’t work.
I did that on my moto e2 with kernel auditor and it still popped.
Its 1.2ghz quadcore with GPU so it is plenty powerful for SNES.
Strange,on Shield TV (Pro) I would get idle time slowdown in Mupen64Plus AE Alphas in some scenarios with GLideN64,and THIS is with the max performance profile mode. Why does the software have to suck so much in comparison to the device it runs on? I would love an update with the GPU actually getting used properly reaching closer to its max 1Ghz clock but mostly no more than 800Mhz on intense stuff. Why is it that the pretty much most powerful Android device is being throttled to hell (200Mhz-300Mhz) when both FireTV models’ GPUs run at 400Mhz and 600Mhz respectively?!?
Quad core should help superfx,sa1.(since they are second cores) (I know the emulator is single threaded but an extra cpu would help this if the emulator used it)
The GPU part is a reference to what is NOT being run on the CPU by the os,thus leaving that many Opcode’s avalible for the emulator.
So 3 1/2 1.2ghz pipelined CPUs for 2 <50mhz CPUs and basic GPU is plenty.
Plus it works on a 2012 nexus 7(that is laggy as hell on lollipop) that is the same accept for being cortex a9.
But I dont have performance issues,the game is running at fullspeed and my cpu says it is only using 70%(of one core,50% on another core,2 cores are off) but it is cracking.
It still cracks even when fingers are on screen.
//insert 30 min post delay
Just installed a different kernel and it still pops but only 1 for each 10 times it used to.
So this must be the kernel being stupid and setting the CPU at 300mhz or something.
Does retroarch try to set its thread priority,because if not the kernel might just think it is ok to let it run at 300mhz and take its time to save battery.
Install kernel auditor,performance setting is your cpu governor the performance governor always runs at least one core of the cpu at the max frequency (so the os cant try to slow it down to save battery)
So you right now your >1ghz tablet could be running at 300mhz because the OS thinks retroarch can take its time,performance overrides what the os thinks and makes it run at max no matter what.
I just fixed crashing superfx emulation on android in catsfc so update it from buildbot tomorrow and see if it works without popping.
My prob with CatSFC is that it uses the older S-SMP/SPC700 audio core, it’s inaccurate, so I usually avoid emulators that sound too much like Zsnes. Any chance at looking at Snes9x or Snes9x Next?
-
Provide an admittedly harsh bug report
-
[QUOTE=Radius;38747]I’m on marshmallow on the same device and it’s just fine except some hickups in mupen. Harlekin just likes to throw hissy fits to the people helping around don’t pay attention to him[/QUOTE]
-
Queue direct reply to user radius to honor his statement and glance over the original posting
You guys are literally the worst.
If your development pipeline breaks down at any point, which happens around Retroarch more often than not (especially on major releases…) - you’ve created your own fraternising ivory tower information loop that makes sure that people providing bug reports get blamed first - and that you’d rather drive out people that still get miffed enough with it to to try to isolate the problem by installing different versions – so you’d have the appearence of a working plattform remaining.
If you managed to build in a systemwide regression - as far as actual performance is concerned and it is not visible by having the framerate counter displayed, or because you are running Nvidia Shield devices that by no means resemble an actual standard of what devices people out there use your builds on ( http://www.forbes.com/sites/jasonevangelho/2015/03/04/theres-one-big-thing-preventing-nvidias-shield-console-from-greatness/#60802fa67222 ) - please, listen to people that are telling you exactly that.
If I am providing a bug report in here - I don’t do it to troll (which seemingly is one of the three base vocables any internet user now has ready in his repartoire (“I like”, “help me” an “bleh - troll” (reserved for instances, where something angers this internet user)) you guys - because this project is long past the point where I would get anything out of a social interaction with other users apart from simple factual based reports on when stuff breaks, because at that point - I feel I have somewhat of an obligation to log in here to give a report. Thats the reason I’m not in the mood to pamper you up either - btw.
If people actually tell you that they have installed and uninstalled different versions of Retroach to isolate an issue, and give you descriptions of certain settings they have tried, and if they especially mention when things break at default settings, the likelyhood of them “lying to you” is lower than humanity ending in our lifetime because of an astroid hit.
Now - the issue I have reported on is real. My first reaction would be, that user Radius doesnt care the first thing about frameaccuracy or emulation speeds and doesnt know what he is talking about - but I can assure you, that the issue of the emulation speed difference in between those two retroarch versions was so blatantly obvious, that there is no way you couldn’t have noticed it, as someone that plays videogames.
If thats not the case - it might also have been deactivating the screen overlay (because hey - its 2016 and people don’t just play on touchscreens - because that input scheme is the worst), rebinded controller bindings, deactivated bilinear filtering, or having enabled scanlines - because those are the base setup options I go through after the vanilla install - before trying to troubleshoot the issue.
“Do you need a screen overlay” should actually be a question asked during setup imho (because I bet most users never find it in settings), there should be a system specific “default button configuration” that takes into account that actually - nowadays most controllers look like Xbox controllers - and should be dynamically remapped in emulators if needed. The prime example for this is switching X and O (or A and B), where you have controller schemes integrated in Retroarch that simply mix those basically at random. TODAY I can connect two different controllers to Retroarch and depending on the Controller config file - they might have confirm mapped to A or B in the Retroarch menu itself (no standard whatsoever), because people made the profiles thinking of specific emulator mappings. Thats actually real messy.
Those two steps alone (maybe add a “do you want the bilinear filter on or off” dialogue at first run as well) would streamline the setup process and minimize additional setting you have to do each times in the settings. It also would help with bug reporting - because if you have “first tier” settings that most users might touch - you are more likely to test against those as well - it would help because people would be more likely to actually report each setting they have touched in addition - because as it is right now - bug reports would have to start with “of course I changed those general settings, but seriously…”
Also - not having default bios paths (different cores look at differet places) have been an issue in the past as well - and that people frequently have to change at least the rom path - so maybe, a setup wizard could ask you for that as well.
Other emulators surface important settings and browsing options (with "last folder sticks systemwide (granted, those are “one console” emulators)) much better than Retroarch at this point - again, which is mostly an accessibility issue for the average user…
I’d also suggest, that you always test changes against at least having the scanline filter active - because the filter feature seams to be quite integral to Retroarch.
That said, I don’t believe the scanline filter is the culprit here, because I distinctly remember deactivating it to see if it had an effect on the performance problem - it didn’t.
Oh, and by the way - you have another “all emulator cores run at a slower speed” issue (this time with a nightly) open on a thread talking about a nightly, go figure…
Also - at the time I have not run a “adb shell top -m 10” to make sure that it wasn’t a different program freaking out, hogging CPU cycles - I have no reason to believe that it was, but at least to show you that I am still open to at least the possibility - that it somehow was my fault.
As far as I am concerned - I might pop back in here once you’ve got your next major release out - although breaking my retroarch installations every time I update (lets sign it differently - yay!) isn’t exactly fun - and reverting to previous installations is another lesson in frustration (because of the setup required (saving .cfg files brings up a whole bunch of different issues…) - because I feel somewhat responsible to at least point out general issues when I am experiencing them.
If you then have people dedicated to beat me down for it, because of how they personally like my tonality, be my guest - whatever it takes to keep your motivation up…
(My last fun interaction with Retroarch? PPSSPP running perfectly in its stand alone version, but crashing on two games within the first 2 minutes in Retroarch. Of course crash to launcher type crashes - because, why not. Core specific settings also had at least one option that never got applied (afair render resolution related). Can you take a guess if I tried messing with different version here as well? Or give an actual bug report? I generally just stop using those parts that are broken and pray that it doesnt get worse…)