Sound Plugin Development

[Azimer]

Tested it using the 2010 toolkit in 2013. Still crashes. Tested in 2010 IDE after creating a fresh project. Still crashes. I believe at this point, I am going to go back to 2013 and keep working on improvements rather than worrying about this crashing issue. It only seems to happen with XAudio2.

My guess... we have an issue with COM removing an object before it's ready to be. It continues to run either the XA2 processing thread while the dll is unloaded or the AiUpdate thread remains active while the dll is unloaded. Either place I am at a loss for what I can do for now. Perhaps someone can help me fixing once it's open source.

It only happens switching plugins which for the majority case will not be a common practice for the end user.

[RPGMaster]

That's unfortunate. I agree with your decision to work on other improvements.

Well, whenever you do open source it, I will definitely take a look and try debugging it.

[HatCat]

I'll bet that adding message boxes at the start and end of each plugin spec function should help. I've had to do that myself a few times. It's actually a shortcut more than a burden ... one unavailable to me when isolating multi-thread OpenGL issues with this spec!

Actually, just adding message boxes at the start and end of each function, might itself fix the crashing/instability you're finding. Some of these spec functions run concurrently...there are times that just adding a message box would fix, or even introduce, a crash. So by holding up the execution of the function and waiting for the user to click something before continuing, the crash never happens.

Better yet, that doesn't fix it but tells you the name of the spec function where the crashing happens. Just an idea for the future.

[Azimer]

Originally Posted by HatCat

I'll bet that adding message boxes at the start and end of each plugin spec function should help. I've had to do that myself a few times. It's actually a shortcut more than a burden ... one unavailable to me when isolating multi-thread OpenGL issues with this spec!

Actually, just adding message boxes at the start and end of each function, might itself fix the crashing/instability you're finding. Some of these spec functions run concurrently...there are times that just adding a message box would fix, or even introduce, a crash. So by holding up the execution of the function and waiting for the user to click something before continuing, the crash never happens.

Better yet, that doesn't fix it but tells you the name of the spec function where the crashing happens. Just an idea for the future.

I hear what you're saying but it's not the issue. For some reason TerminateThread is NOT terminating the AiUpdate thread so all those threads hanging out there are crashing when the audio plugin is unloaded. I made a work around that works for Project64 and Apollo at least. I am hoping they work for 1964 and Mupen.

New test release WIP 4

[HatCat]

Well, at any rate whatever was the exact cause of it, it's gone now. No amount of plugin-switching and/or ROM changing in-between seems to crash your XA plugin anymore on 1964/mupen, so all instabilities appear to have vanished. (Still can't test your DS8 plugin though because it still locks up my system--no loss quite honestly. If I'm going to use a DirectX plugin I'd much rather use XAudio.)


I've found the source of the "wxWidgets" pop-up message me and RPGMaster have been getting, that you haven't been seeing.

I deleted all plugins from my plugin folder, except for yours and Glide64 Final release. If I delete either of those 2 plugins, the pop-up goes away. So for some reason, your XAudio application is conflicting with something Gonetz did in Glide64 final.

[RPGMaster]

Good news is the plugin switching problem is now solved. Bad news is that pausing is broken in 1964. I tried the DS8 WIP 1 and WIP4, when I pause the emulator in 1964 1.1, it mutes the sound after unpausing. I got a messagebox saying "Error Locking Sound Buffer" after pausing.

Now with the XA2 version, WIP4 has a regression where I can't load save states. Also pausing is broken. If I pause, and then unpause, the emulator is frozen. In WIP2 and probably WIP1, I was able to pause and unpause, but I'd get more crackling from then on.

Otherwise everything else seems good, aside from that annoying wxwidgets message box. Mupen64 0.5.1 works well with WIP 4.

Lol I had a feeling Glide64 final might have something to do with it ;/ . Because I know it uses wxwidgets.

[HatCat]

Azimer, quickest way to reproduce that wxWidgets pop-up (though I know this may not be quick enough for you since you don't have Mupen64 handy):

1) Install Mupen64 0.5 for Windows. This is the only emulator that the pop-up message seems to always come up on immediately upon opening the m64 EXE, no matter what plugins you have currently selected or what your options are.

2) Have Glide64 Final installed to Plugins folder for Mupen64. Also, your XAudio2 plugin (DS8 doesn't have the issue) must also be installed as a plugin.

3) Open Mupen64.exe and you should immediately see:

[Azimer]

Thanks for the responses. The trouble I am having is every emulator implements the spec differently and I have to do some things a different way depending on the emulator. It's a bad design in the specification not to include specifics of implementation.

Thanks for the note on the regressions. I will do my best to fix those in the future but as long as the plugin "works", I am satisfied. For now, I am going to focus on PJ 2.1 to finish the zilmar spec implementation. I may need to do emulator specific hacks. Who knows.

About Glide64, I find that peculiar. The only thing I can think of is COM. There must be a connection somewhere and it's making a lot of things more difficult to debug and track down. I have no problem with AiUpdate until I started using XAudio2.

[HatCat]

I don't use 1964 1.1 anyway because the goddamn GUI freezes 50% of the time that I open any rom whatsoever.

But on Mupen64, pj64 1.6/2.1 and Apollo the current plugin seems stable enough to me. I didn't notice regressions. Emulator-specific plugin system hacks are an ugly business, but it depends what's currently wrong. Sometimes I just leave shit broken on purpose rather than implement emu-specific hacks.

[RPGMaster]

Originally Posted by Azimer

Thanks for the responses. The trouble I am having is every emulator implements the spec differently and I have to do some things a different way depending on the emulator. It's a bad design in the specification not to include specifics of implementation.

Thanks for the note on the regressions. I will do my best to fix those in the future but as long as the plugin "works", I am satisfied. For now, I am going to focus on PJ 2.1 to finish the zilmar spec implementation. I may need to do emulator specific hacks. Who knows.

About Glide64, I find that peculiar. The only thing I can think of is COM. There must be a connection somewhere and it's making a lot of things more difficult to debug and track down. I have no problem with AiUpdate until I started using XAudio2.

Ya emulator specific problems are indeed a pain. At this point, I think you should focus on whatever is important to you. Even though I'm a 1964 fanboy, hardly anyone else uses it ;/ . But if you know a convenient way to do emulator specific hacks, then that's fine too.

I think it might be better to leave some of these problems for other people to solve since you plan on open sourcing it. Honestly, for 1964, WIP2 does the job good enough. Sure plugin switching is a pain and pausing the emulator is buggy, but HLE musyx + less crackling is worth it. After you release the source, I may even be able to fix some of 1964's flaws in it's source code. I think the way they handle sound seems odd.

Originally Posted by HatCat

I don't use 1964 1.1 anyway because the goddamn GUI freezes 50% of the time that I open any rom whatsoever.

Kinda sad how unofficial versions > 1964, although both of the ones I know of, have some regressions.

Originally Posted by HatCat

But on Mupen64, pj64 1.6/2.1 and Apollo the current plugin seems stable enough to me. I didn't notice regressions.

Indeed.

Originally Posted by HatCat

Emulator-specific plugin system hacks are an ugly business, but it depends what's currently wrong. Sometimes I just leave shit broken on purpose rather than implement emu-specific hacks.

I agree. If the fault is solely due to the emulator, then the emulator should be fixed, not the plugin.