Sound Plugin Development

[HatCat]

In a hurry to bump these threads over some other retarded ones in this forum, I figured I'd post something semi-on-topic in this thread.

I was just reading about audio cracking reports on EmuTalk with this plugin:
http://www.emutalk.net/threads/55161...Feedback/page4

To a small extent, I find I hear them slightly too, with Project64 1.6 (which has no Fixed Audio Timing option for me to toggle). I usually finish my Quest 64 save file now, but I tried Super Mario 64 too and get the sort of random-frequency clicks talked about in that thread...sometimes every 5 seconds, sometimes 20 seconds, sometimes 3 sec. FPS (VI/s) is 59.98 to 60.02 I think (tested with HLE gfx ofc, not my OpenGL build of angrylion's pixel-accurate RDP)...actually wasn't paying attention if the pops may have happened around the time of FPS further outside that range. No amount of changing options in the XAudio2 plugin settings seemed to modify the issue...I wonder if it's just my CPU usage from other processes being unpredictable or something else about my system. (I never use Force Old School audio sync option.)

[Azimer]

I will try it in PJ 1.6. It shouldn't be happening and I wonder if it's the audio plugin's sound engine or the audio interface emulation causing the game's engine to mess up.

[HatCat]

RPGMaster what about you? Can you make out any clicks in something like Super Mario 64, when running emulation at 60 VI/s, on Project64 1.6 / other emus?

If not, any ideas of why it might be unique to just me / that guy in the EmuTalk thread?

[RPGMaster]

Well I just tried PJ64 1.6 and WIP4. I only heard crackling in the intro. What part of the game has this issue? I'm using 2 for CF. I just tried starting a new file and am just walking around.

I suspect the issue might be partially due to emulator settings, because I know things like counter factor can have a significant impact on audio.

Wow wth.. Seems like crackling is random. I see why I get confused now. It still doesn't seem to happen to me as often as other people are saying. Most of the time, I don't even hear any crackling. I think I hear more crackling when my laptop gets hot or is running too many things ;/ . So it could be cpu related. I'm also using HLE for audio, if that makes a difference.

[HatCat]

Ah sorry I was meaning to mention this.

I just let it sit on the SELECT FILE screen where all the animation is perfectly still (nonexistent). That's how I tested the audio.

But yeah, it kinda happened during the intro too.

Counter Factor? I'm using CF=1; could that be it?

[HatCat]

[RPGMaster]

Originally Posted by HatCat

Counter Factor? I'm using CF=1; could that be it?

I got more crackling in SSB64 with CF 1. I can try CF 1 in SM64 right now.

Also I got a dll unloaded error with WIP4 in PJ64 1.6.

Edit: I tried SM64 with your exact settings, I don't think I notice much of a difference ;/ . Crackling for me doesn't happen often and seems to be random. When I just stay at file selection, I don't hear any crackling at all, on either CF = 1 or CF = 2.

Rofl, now I can't even re-test SSB64's intro since it keeps freezing. Anyway, CF=2 generally seems more stable, but I guess it's game specific and possibly emulator specific too. So if you don't notice a difference between CF=1 and CF=2, then CF=1 is probably better.

[RPGMaster]

So I've been tweaking 1964's HLE audio code since I'm trying to learn how to HLE the RSP. Spent 2 hours trying to fix a regression I made. The problem was literally 2 typos caused 2 different problems ;/ . Even if I'm not able to significantly speed up the HLE code, I'd like to remove some code bloat . The plugin is > 3mb already.

I seriously need a good way to catch regressions. Thank goodness for windows 7's file recovery feature because I didn't even have a backup ;/ .

Decompiling the RSP code per game seems relatively straightforward. I just need to figure out more details before I'm able to do my own implementation. Right now, 1964's HLE looks like spaghetti code to me, so it limits what optimizations I can do. I'll have to do research on microcodes.

Do you guys know a good way to catch regressions? My current method is to simply restore previous code, piece by piece. Lol it's kinda hard for me to detect regressions for HLE audio, since my hearing isn't too good ;/ . Fortunately, most of the mistakes I've made so far have caused very noticable problems.

One weird thing I've noticed is that certain sound problems I have, tend to only happen randomly. It's kinda confusing sometimes because when I hear problems with audio, I just assume something's wrong with the plugin, but I now see that sometimes, it's just my computer. I'm guessing other programs I'm running may be interfering, or maybe my computer is just too hot.

I recently noticed that Azimer's XAudio version has stuttering problems on my machine in SSB64's intro, while DS8 version does not. I've tested it on 1964 1.1, PJ64 1.4 AFE, and Mupen64 0.5.1.

[Azimer]

Testing for regressions is a pain in the ass. I mostly have a set of roms I use a test images and cycle through them when I make every incremental change to ensure I don't mess something up. If it's a major rewrite, I copy the source file so I can refer to it later if I end up with serious regressions. That is all I can suggest.

SSB is annoying and part of my cycle of test roms. The XA2 plugin works best with PJ 2.x.

I am releasing my source code for all to contribute to on github. https://github.com/Azimer/AziAudio

[Ambient_Malice]

Originally Posted by Azimer

Testing for regressions is a pain in the ass. I mostly have a set of roms I use a test images and cycle through them when I make every incremental change to ensure I don't mess something up. If it's a major rewrite, I copy the source file so I can refer to it later if I end up with serious regressions. That is all I can suggest.

SSB is annoying and part of my cycle of test roms. The XA2 plugin works best with PJ 2.x.

I am releasing my source code for all to contribute to on github. https://github.com/Azimer/AziAudio

Azimer, you are a hero.