Sound Plugin Development

RPGMaster · #1 6th June 2014, 06:11 PM

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.

Code:

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 · #2 6th June 2014, 06:54 PM

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 · #3 6th June 2014, 09:59 PM

Quote:

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 · #4 6th June 2014, 10:06 PM

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 · #5 6th June 2014, 10:31 PM

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 · #6 6th June 2014, 11:12 PM

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"....

HatCat · #7 6th June 2014, 11:46 PM

Quote: