New LLE RSP Plugin (accurate, fast but untested?)

[RPGMaster]

After trying a few games with the intel sse4 build, I saw that GCC sse4 and Intel sse4 are pretty close. My debugger is acting weird so I'll put that on hold for now lol. Time to work on sound .

For sound, do you think we'd need per game settings? Or would a good implementation work well for every game?

Also, do you think PGO would be worth trying out for rsp and gfx?

This sound testing stuff's complicated lol. It's like plugins were designed to be used with specific settings. For instance azimer's audio is more in sync when I use pj64 1.6 interpreter with CF = 2. I usually play on CF = 1, but now I need to figure out how that setting works. I've also been looking at Mupen 0.5's source. I must say, it's very clean . I'd say it's easier to understand than 1.6 or 1964 0.85.

I also need to figure out how to fix an emulator core so that audio works more accurately. I wouldn't want to design a plugin to only be good with a specific emulator + specific settings.

[userss]

cant say enythink its better

[MarathonMan]

Originally Posted by RPGMaster

Also, do you think PGO would be worth trying out for rsp and gfx?

FWIW, I saw a ~5%+ speed boost across all ROMs, even though I only "trained" the binary with PGO using one specific ROM. It's easy enough to do with gcc that it can't hurt to try, and I'll be surprised if you don't get at least some improvement, however minor.

Speaking of compiler assisted optimizations, it would be nice if somebody ran UBSan on all these plugins and scrubbed any remaining undefined behaviour out of them (if there is some).

[RPGMaster]

In that case, I'll experiment with PGO.

Speaking of UB... After updating Clang, even that compiler won't work with Zilmar's Basic Audio now... There must be a lot of UB in that source code.

Does anyone know what counter factor Mupen 0.5.1 uses? It seems to have the best audio timing out of the big 3 (Pj64, Mupen, and 1964). I also heard less crackling. For pj64 and 1964, the audio improved when I switched from CF = 1 to CF = 2.

Edit: I found the issue. It's so weird when things work fine on 1 compiler, but are broken on another. After looking closely at the assembly code, I realized what the error was.

rgdscbpn[3].dwOffset = DSBPN_OFFSETSTOP;
rgdscbpn[3].hEventNotify = rghEvent[3];

rgdscbpn only has 3 slots, not 4, so that code needs to get erased. I guess some compilers handle things differently. It's weird how with the buggy code, it worked with Intel if SetupDSoundBuffers wasn't inlined. Next time I run into a problem where it works on one compiler but not the other, I'll try to fix the problem instead of relying on the compiler it works for.

[V1del]

Mupen uses counter factor 2, this has recently been made configurable in m64p as well see https://github.com/mupen64plus/mupen...b9f10c9ce0e866 for reference

[zuzma]

@RPGMaster

I only recall it being used to fix freezing games in mupen64plus not for anything audio related. I think there was one case where it sped up killer instinct gold for mobile devices. Don't remember the CountPerOp setting though. All you have to do to change it is add in CountPerOp=(number) into the mupen64plus.ini file.

edit: Too bad most of the frontends for m64p are derpy as fuck. It'd really stand out if it was easier to use. : p

[HatCat]

I don't really mind Mupen64Plus as a theoretically console-only application (better than the GUI-only 1964 winapi, except not even that if it makes me ctrlaltdel all the time!); I'd just rather pay a little more attention to what people like Hacktarux are doing with the r4k interpreter, instead of what okaygo and some other guys are doing with recompiler + some features.

Edit: Yeah RPGMaster I remember finding something like that too. He was doing modulus by 3 even though there were 4 array elements or, something like that. Maybe there are 4 sound buffers or states, and he accidentally declaed it as 3? Or hell, maybe you fixed it already. :P

[RPGMaster]

Thanks for the info guys. I didn't know 2 was the most stable, until recently . I thought it just had to do with computer speed.

Originally Posted by HatCat

I don't really mind Mupen64Plus as a theoretically console-only application (better than the GUI-only 1964 winapi, except not even that if it makes me ctrlaltdel all the time!); I'd just rather pay a little more attention to what people like Hacktarux are doing with the r4k interpreter, instead of what okaygo and some other guys are doing with recompiler + some features.

Edit: Yeah RPGMaster I remember finding something like that too. He was doing modulus by 3 even though there were 4 array elements or, something like that. Maybe there are 4 sound buffers or states, and he accidentally declaed it as 3? Or hell, maybe you fixed it already. :P

I agree with you about paying attention to Hacktarux's code rather than the other ones. His code is certainly the easiest to follow. I'd personally prefer winapi over stdio, but it's still good. Do you have the slightest idea what part of the code would impact things like audio timing? I know it's probably in the cpu section.

For the fix I just commented out that part. I may just add 1 to the total array size and uncomment the code. I haven't noticed a difference between the 2 yet. Lol I have no idea what I'm doing. I tried doing 6 buffers instead of 3 and it was all jacked up xD. That's what happens when I mess around with stuff before reading the basics ;/ . Since it's been stated that emulators aren't accurate enough for CF = 1, I'll base everything off of CF = 2.

I tried Mupen64plus yesterday, and idk if it's the core or the plugins, but it didn't seem as smooth as mupen64 0.5.1. I'm thinking maybe it was just the plugins. Not many to choose from lol.

[GPDP]

Based solely on my own experiences, the standalone version has had issues for a while now, at least on Windows. I've pretty much given up on it and use the libretro version instead, which runs far better for me. Only thing it hasn't implemented is the z64 plugin, but they're adding Angrylion's plugin instead.

[V1del]

@GPDP
can't really confirm that, but w.e. retroarch is a tad easier since it automatically activates options which aren't exactly deemed necessary but may be wanted for an effect or two (at a speed hit)

@RPGMaker
From what I understand the whole concept of setting a CF is a hack because the emus aren't cycle accurate, CF = 1 isn't necessarily "more accurate" in general.
As for slower performance on mupen that could really be the plugins, they all use opengl and your video hardware seems to struggle with it as you have mentioned a few times