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

[HatCat]

Like I mentioned before one good service you can do yourself is to upgrade from DirectSound... 7 was it? Or zilmar's audio uses DS6, can't remember. But upgrade to DirectSound8.

There are some separately named structures and functions for DirectSound8.

For example:

IDirectSound8       *ds; // instead of IDirectSound
IDirectSoundBuffer8 *dsbuf8; // instead of IDirectSoundBuffer

... and ...

hr = DirectSoundCreate8(NULL, &ds, NULL);
// instead of hr = DirectSoundCreate( ...

Dunno why, but just doing this was enough to improve the sound quality and reduce the crackling. It does not however eliminate it. I don't know exactly what else you can do about that problem besides playing with the number of buffers and their lengths maybe, upgrading to XAudio2 perhaps...I'm sure Azimer would have some better insight on this.

[RPGMaster]

Man... I need to search for directions before wasting time. I totally forgot about this guy's githib, he had everything set up nicely.

Now I can finally tweak the rsp recompiler . Do you still have your zilmar audio build by any chance? Lol when i switch plugins while playing a game, the emulator crashes. I tracked it down and the cause is that sometimes lpdsbuf would have an incorrect value. So I had to make a hacky solution to prevent the emulator from crashing. I'm wondering if my compiler is the cause or the plugin code. Somehow, compiling with MSVC causes SSB64(U) not to work lol...

I really should make a github repo. Too lazy atm though. After a lot of trial and error, I finally got 2.1 to compile!

[HatCat]

Who's GitHub? Something about the audio plugin or a RSP emulator?

No I don't think I still have my zilmar audio build handy...I still have some source file somewhere, but they should be much more widely available after Shunyuan re-released my source + his own build of it, titled "FatCat's audio". He even renamed the DLLs and everything from zilmar audio to fatcats audio to make it look like it was my own plugin.

[RPGMaster]

Originally Posted by HatCat

Who's GitHub? Something about the audio plugin or a RSP emulator?

No I don't think I still have my zilmar audio build handy...I still have some source file somewhere, but they should be much more widely available after Shunyuan re-released my source + his own build of it, titled "FatCat's audio". He even renamed the DLLs and everything from zilmar audio to fatcats audio to make it look like it was my own plugin.

https://github.com/JunielKatarn/Project64 . It has glide, pj64, and rsp. I still had a few issues though. PJ64 was set up to require Glide64 to build and I can't get glide64 to build because I can't get wxbase to build lol... So I had to remove that dependency. I want to compile Glide, so i can profile it, so hopefully I can figure it out. Lol unfortunately, I couldn't be bothered with all that C++ code, so I gave up on trying to see if I could improve / fix the debugger. I still might try and modify the core though. Hopefully one day, I can replace the slow fpu code with sse for the recompiler, but that's assuming there aren't any unique FPU instructions that I can't do with sse.

I guess I'll search around for your source so i can see the difference between your's and Zilmar's original. Idk why more sound plugins don't have a buffer size adjustment. It's nice to be able to adjust it on the fly, rather than some preset number.

I'm really digging the ability to conveniently debug a dll! Before, I thought the only real way was to debug at assembly level lol.

[HatCat]

You would probably implement a buffer size adjustment feature then since that is one of the few things that zilmar went on to implement in his own audio plugin, after releasing the Basic Audio Plugin source.

If there was anything else so significant about the audio source, that I remembered changing in my own fork of the basic audio plugin, I would have told you. Most of my other changes were for more compliant C-ish syntax and just experiments to learn more about DirectSound and audio (possibly hazardous ones). Using what I did as a source base won't just re-teach those experiments.

[RPGMaster]

Oh alright then. I guess I'll just assume your version probably has the same issue. It could also just be my compiler since simply using a different compiler got rid of that SSB64 error lol...

I was messing with the debugger in pj64 1.6 (since it has breakpoints) and it seems that pausing the emulator with F2 doesn't always pause at the same place. I'm really curious how Nemu's debugger works since it uses a recompiler. With pj64 1.6, you can't use breakpoints unless you're in interpreter mode That means in order for me to be able to TAS effectfively in PJ64, I'd probably have to use interpreter lol.

Speaking of interpreter mode, something interesting I noticed while using PJ64's and 1964's built in profilers, was that some plugins like jabo 1.6 and 1.52 used less % when using interpreter. I only say "some" because I didn't try too many xD. I'm wondering if there's a flaw in the profiler. For instance when I uncaped my cpu (i usually cap it to prevent laptop from overheating) and use Jabo, on 1964 0.85, I'd get ~30% of emulator's time spent on interpreter core, and ~30% for Jabo plugin. With recompiler, I'd get like 7% for core and maybe something like 38 or 40% for Jabo. Both pj64 and 1964 had significant differences for the Dlist cpu usage when switching to interpreter.

Hopefully I can learn a lot about audio stuff today.

[HatCat]

I don't remember there ever being a SSB64 error. You said it was spitting out DSERR_INVALIDPARAMS when you lost SSB? What line or DirectSound function was it that gave you that?

I don't think it's realistically possible to constantly debug the N64 as a state machine while it's being emulated by means of re-compilation, so maybe turning on those debug options in Nemu, probably just enables the interpreter mode implicitly.

[RPGMaster]

Originally Posted by HatCat

I don't remember there ever being a SSB64 error. You said it was spitting out DSERR_INVALIDPARAMS when you lost SSB? What line or DirectSound function was it that gave you that?

The program gets stuck here

if ( FAILED( hr = IDirectSound8_CreateSoundBuffer(lpds, &dsbdesc, &lpdsbuf, NULL ) ) ) {
		DisplayError("Failed in creation of Play buffer 1");	
	}

I really don't get why using a different compiler solves the problem. Also even J version works fine though lol.. Zilmar's released plugin also works fine. I wish I could debug, but when I use clang on MSVC, the debugger can't display a variable's values.

Originally Posted by HatCat

I don't think it's realistically possible to constantly debug the N64 as a state machine while it's being emulated by means of re-compilation, so maybe turning on those debug options in Nemu, probably just enables the interpreter mode implicitly.

Lol I thought so. Although I still think it does some sort of mix, because emulator isn't slow when I debug (while pj64 is extra slow). Unless Nemu has some super fantastic interpreter lol.

[HatCat]

>IDirectSound8_CreateSoundBuffer

When you said that, that's not zilmar's released plugin or his original code. That's a DirectSound8 function. I'm not even sure whether DirectSound8 was out at the time zilmar made these plugins (ca. 2000 A.D.).

Of course, I did recommend you to upgrade to DirectSound8 code and functions. I think it's good that you did that. However, the DSERR_INVALIDPARAM error might be because a non-DirectSound8 object is being passed to that function. Is `lpds' declared as LPDIRECTSOUND or LPDIRECTSOUND8?

You're using Microsoft Visual Studio to interface with Clang? Bad idea if it means you can't use Microsoft's official linker (their `LINK.EXE') to produce the final DLL plugin. Usually the .obj object files are a specific thing that only works with Microsoft's compiler package. Don't use Clang for something this Windows-specific. Hell, I wouldn't even use GCC or MinGW for this on Windows. It's just an audio plugin. There's no bottleneck here to optimize, unless potentially when you start to add HLE of the RSP microcode tasks in it.

[RPGMaster]

I only tried clang for this plugin to see the difference. In fact most projects I've downloaded can't even compile with Clang because it's very strict and does not support every feature yet (especially C++ stuff). Also, I believe it does use MSVC's linker. I should have mentioned that I had the same problem before changing it to DirectSound8_CreateSoundBuffer. I'm thinking there's something wrong with my compiler because changing compilers should not fix anything broken lol, yet it did. I'll go ahead and try MSVC 2013 and see if I have the same problem.

Edit: I confirmed MSVC is doing some weird stuff. I was silly trying to debug in high level... So after debugging at assembly level, I noticed something unusual. That if(FAILED) statement, gets executed twice when running SSB64 (U). When I set a breakpoint right before it calls the function, I copied the values of eax - ebp. I noticed the second time around, the values of the registers were different, yet in Clang they remained the same.

MSVC
1st
EAX = 6D031F6F EBX = 04500010 ECX = 6D02D7D8 EDX = 0778F8EC ESI = 00000010 EDI = 77464327 ESP = 0778F8A0 EBP = 0778F994
2nd
EAX = 6D050012 EBX = 04500010 ECX = 6D0033F0 EDX = 0778F8E4 ESI = 00000010 EDI = 77464327 ESP = 0778F898 EBP = 0778F994

Clang
1st
EAX = 06E21B88 EBX = 04500010 ECX = 6D02D7D8 EDX = 06DDF870 ESI = 00000010 EDI = 77464327 ESP = 06DDF830 EBP = 06DDF90C 
2nd
EAX = 06E21B88 EBX = 04500010 ECX = 6D02D7D8 EDX = 06DDF870 ESI = 00000010 EDI = 77464327 ESP = 06DDF830 EBP = 06DDF90C

In fact, the MSVC version even calls a different function the 2nd time, due to the values of the registers being different (MSVC calls eax).

Strange thing is, for SSB64(U), it calls SetupDSoundBuffers(); twice while J version doesn't.