Sound Plugin Development

[RPGMaster]

Hello, I'm trying to develop a sound plugin and would like some advice . So far I've looked at Zilmar's Basic Audio and 1964 Audio. I've tried changing things around to see what happens. I'm understanding more and more of it.

One thing I need help with is buffers. I tried adding more buffers, but the sound was kinda weird. I probably messed up with the algorithm somewhere. Strange thing is, adding an extra buffer to Zilmar's audio, made SSB64's intro more in sync, but that didn't work for 1964 Audio.

I also tried seeing how to reduce crackling. 1964 Audio's sync audio does the job well, but at the price of fps. Lowering the sleep time from 10ms to 8 sorta helped, but it's not a perfect solution. I thought about implementing SSE for the ucode stuff. Problem is, the main part I need to optimize has too many if statements ;/ . If I were to get the cpu usage of the audio plugin down, I might be able to get stable 60fps with sync audio.

Here's a macro that is a bottleneck.

VMULF_operation(index, dest, s1, s2, wrElement, wrHiAccum, wrLoAccum, wrFlag0) {
	if (wrElement || wrHiAccum || wrLoAccum) {									
		_s32	result = ((_s32)(_s16)(s1) * (_s32)(_s16)(s2));					
		if (wrLoAccum) accumulator[index] = (((_u16)(result << 1)) ^ 0x8000);	
		if (wrElement || wrHiAccum) {											
			_s32	hiValue = (result >> 15);									
			if (result & 0x4000) hiValue++;										
			if (wrHiAccum) accumulator_hi[index].S32 = hiValue;					
			if (wrElement) {													
				Vector_ClampValue(hiValue);										
				(*(_u16*)&(dest)) = (_u16)hiValue;								
			}
		}
	}	
}

In the meantime, I'll try learning the API for DSound and XAudio2.

Also, which do you guys think is more accurate for your typical commercial game, using 1964 HLE audio, or LLE using PJ64's RSP recompiler? I know the HLE one doesn't support every game yet.

[HatCat]

Now that is unfortunate. HLE was based on interpreter ops from pj64 rsp? Seems like a waste.

You knew that's what VMULF is, right? An RSP opcode?

[RPGMaster]

Originally Posted by HatCat

Now that is unfortunate. HLE was based on interpreter ops from pj64 rsp? Seems like a waste.

You knew that's what VMULF is, right? An RSP opcode?

It does kind of seem like a waste, but perhaps maybe it's as accurate as an interpreter? Idk how I'll even be able to tell the difference in accuracy.

Ya I saw VMULF in your rsp plugin. 1964 Audio's HLE is only a little slower than RSP recompiler, if not approximately equal in speed, but if I was able to use sse for VMULF and some other slow ones, it would be much faster.

Lol everything made by 1964 has optimizations disabled. Sound, Video, and Emulator all had significant improvements, when I turned on optimization. The bad thing about these products is that they pretty much only work for MSVC's compiler. Good thing I'm used to MSVC though .

That macro I posted is used 8 times consecutively. Would there be any way to do it less than 8 times? It has too many if statements for me to figure out how to use SSE to do at least 4 at a time. I should practice SSE algorithms.

It seems like sound plugin performance is heavily dependant on your hardware too, because if I use sync audio and disable video, I always get 60 VI/s, so that means I just don't have enough cpu power to use sync audio and still get 0 crackling sounds. I'm sure there are better implementations, because Jabo's sound does 60fps in some games at least, but the timing is sometimes more messed up with sync audio on.

So far the only ideas I have for actually improving the sound plugin, aside from optimization related stuff, is to add more options. Not enough sound plugins have adjustable buffering, and also for sync audio, it would be nice to select the exact millisecond sleep time. At the very least, I wouldn't have to constantly compile it, just to change the timing and buffer size xD.

I"ve briefly looked at Azimer's old source, it's pretty good. His HLE approach is much different than 1964's.

[HatCat]

I wouldn't even use that algorithm at all, never mind repeating it.

Neither the recompiler nor interpreter RSP ops in PJ64 accurately represent the behavior of the VMULF operation.

[RPGMaster]

Rofl thanks for clarifying. I had a feeling that algorithm was weird. Too many if statements . So basically the HLE implementation needs a rewrite. I kinda do think it's cool the way they did it, but at the same time, it's inefficient the way they mixed assembly with c. I guess at the time they wrote it, gcc wasn't that good? Who knows lol. Good thing the inefficient stuff had hardly any impact on performance. The only expensive stuff were macro's like VMULF, and I forgot the other ones. I think VMACF was one of the other expensive ones.

Sigh, I wouldn't want to spend a lot of time on learning RSP stuff, just to implement HLE. Maybe for now, I will attempt to fix the algorithms though. I'll need to find documentation.

I was hoping this current HLE implementation was at least more accurate than PJ64's RSP recompiler.

Lol now I'm looking at Pj64 2.1's RSP.

[Wally123]

While I cannot give coding advice...I would add a gausain filter to the mix to allow for less harsh sounding midtones that blast speakers to death. Prime example...Zelda OOT pressing "C-Left"....

[RPGMaster]

Originally Posted by Wally123

While I cannot give coding advice...I would add a gausain filter to the mix to allow for less harsh sounding midtones that blast speakers to death. Prime example...Zelda OOT pressing "C-Left"....

Thanks. I appreciate your advice. I'm not very knowledgable when it comes to sound, but I'm willing to learn. Lol i can't remember the last time I've seen that in sound options, since ZSNES.

Even learning API could help me improve the plugin, even if I can't improve the main code base quite yet.

[HatCat]

the fuck is he talking about


Yeah I can't emulate the RSP worth a damn, so I'll just add a Gaussian blur filter so no one can make out my source code.

[HatCat]

Originally Posted by RPGMaster

I guess at the time they wrote it, gcc wasn't that good? Who knows lol.

No it's because PJ64 Team are Win32 developers.
Don't ask me why nobody uses GCC. Everyone doing emulators for Windows just uses Visual Studio all the time. Even I do sometimes; it depends whether I'm making a plugin an emulator or what.

Originally Posted by RPGMaster

Good thing the inefficient stuff had hardly any impact on performance. The only expensive stuff were macro's like VMULF, and I forgot the other ones.

Yeah, VMULF is the most common in ABI1 audio ucodes I think. It's the most commonly encountered RSP opcode in audio...definitely not graphics though.

Also, VMADN and VMADH. I know VMADH is extremely populated in both audio and gfx ucodes, but VMADN ... it's extremely populated (even more so sometimes than VMADH) in either graphics or audio, can't remember which one.

Originally Posted by RPGMaster

Sigh, I wouldn't want to spend a lot of time on learning RSP stuff, just to implement HLE.

Then don't dive into HLE? LLE is simpler. If you don't like the extra work why worry?

Originally Posted by RPGMaster

Maybe for now, I will attempt to fix the algorithms though. I'll need to find documentation.

Audio HLE is documented but I have no idea where. Maybe in some functions reference manuals or sdk of some sort.

Originally Posted by RPGMaster

I was hoping this current HLE implementation was at least more accurate than PJ64's RSP recompiler.

Not only that, but HLE is more accurate than PJ64's RSP interpreter too, because the interpreter ops are full of extraneous, unnecessary virtual overhead and excessive steps, partly because of great segmentation of the 128-bit vr's active in operation and also memory endianness with the way unions are employed. It's actually rather hazard-prone.

Originally Posted by RPGMaster

Lol now I'm looking at Pj64 2.1's RSP.

k, not much to learn though

[Wally123]

Originally Posted by HatCat

No it's because PJ64 Team are Win32 developers.
Don't ask me why nobody uses GCC. Everyone doing emulators for Windows just uses Visual Studio all the time. Even I do sometimes; it depends whether I'm making a plugin an emulator or what.



Yeah, VMULF is the most common in ABI1 audio ucodes I think. It's the most commonly encountered RSP opcode in audio...definitely not graphics though.

Also, VMADN and VMADH. I know VMADH is extremely populated in both audio and gfx ucodes, but VMADN ... it's extremely populated (even more so sometimes than VMADH) in either graphics or audio, can't remember which one.



Then don't dive into HLE? LLE is simpler. If you don't like the extra work why worry?



Audio HLE is documented but I have no idea where. Maybe in some functions reference manuals or sdk of some sort.



Not only that, but HLE is more accurate than PJ64's RSP interpreter too, because the interpreter ops are full of extraneous, unnecessary virtual overhead and excessive steps, partly because of great segmentation of the 128-bit vr's active in operation and also memory endianness with the way unions are employed. It's actually rather hazard-prone.



k, not much to learn though

The Default RSP doesn't handle High Level Audio very well outside the realm of DirectSound...which is why when I use an audio plugin with XAudio2...I use RSP Plugin versionm 1.7.0.9.