Plugin seems to conflict with something

[mmotti]

RME UFX III

Issue occurs where it sounds like someone has a jackhammer and it completely screws Windows audio and resets all of my manual soundmixer output device changes to default, disables audio enhancements on my RME UFX III "speakers" output etc.

Can't tell exactly what causes this to occur but it renders this plugin not usable.

[atkAudioUser]

what filter? If youre accessing youre hardware with e.g. DeviceIo, check device sample rate settings.

[mmotti]

PluginHost2 with the RME ASIO device selected (all inputs).

OBS audio outputs created and mapped to MIC, System, VOIP, Spotify, Browser, SFX etc (corresponding ASIO loopback devices on my interface).

Sample rate / buffer size all correct. In fact, after updating the plugin (where it has to uninstall the previous version to upadate) it managed to reset the sample rate that I'd previously selected and it had set to 32K or something instead of 48K. The moment I changed it back to 48K the jack hammer started again, all of my preferences within sound mixer were reset as were the preferences I'd set within any application to use specific input / output devices. It's like it screwed up the entire windows audio stack.

powershell.exe -Command "Start-Process 'C:\Windows\System32\control.exe' -ArgumentList 'mmsys.cpl'" (shortcut on the taskbar) came up with a message to say there were errors with the audio enhancements on my default RME speaker device (despite none being enabled) and that Windows had disabled them.

--

OBS, Gig Performer and TotalMix open. RME allows multi-asio connections.

There is a fundamental issue somewhere with the atkAudio plugin that causes a substantial headache to undo every time it happens.

Edit: This isn't the first time i've been stuck with the jackhammer either - It happened in the last release too but this one seems to occur more often. Either way, it's not usable in it's current state with how much damage it causes by Windows resetting everything audio related.

[atkAudioUser]

With RME devices, the sample rate switch can change the WDM driver device configuration, i.e. temporarily "lose/restore" WDM audio devices. The plugin itself has no special access to hardware, basically only Windows Audio / ASIO through JUCE framework. However, if you restored the original sample rate, the original WDM config should be restored also. There is also possibility of sample rate mismatch between WDM and ASIO clients.

[mmotti]

I’m not entirely sure. The sample rate for Gig Performer, for example, is 48k. OBS atkAudio had been set to 48k but had reverted to 32K (or something in the 30s) presumably as part of the plugin upgrade.

The WDM sample rate for the RME capture / render devices is all set to 48k too.

The only things I can tell you are:

1. The sample rate within atkAudio pluginhost2 somehow got reset from what I’d previously set. Possibly due to updating the plugin today which required an uninstall / install as part of the upgrade process.
2. This is a problem exclusively to atkAudio on my machine. No other asio application has ever caused such issues.

[atkAudioUser]

Does this happens every time when you start OBS?

[mmotti]

Does this happens every time when you start OBS?

I’m not sure. I’ll have to double check in the near future.

I’ve reverted to a WDM configuration for OBS for now and when I’m happy things are back to normal I’ll take a macrium image and then play around from there so it’s not as much of a hassle to get everything reset.

[atkAudioUser]

Ok. In any case, that does sound like a samplerate mismatch situation: if there was multiple ASIO and/or WDM clients accessing the same hardware, and then one, atkaudio plugin in this case, tried to change samplerate or buffersize, which could lead to audio discontinuities/last buffer playing repeatedly. In which case, matching samplerates and buffersizes, shutting down everything and restarting the device is usually the easiest way to restore things.

[mmotti]

Yeah it does seem to be the case. I guess the question is how or why the atkAudio plugin host2 decided to revert the asio sample rate to something else outside of what I specified.

The unfortunate thing is that once that issue occurred it did take a reboot of my windows machine to resolve the issue / jackhammer sound, but sadly once the audio system is rebuilt after this happens, none of the sound mixer / general WDM device output settings specified anywhere are kept even after a reboot.

So whilst a reboot may fix the jackhammer thing temporarily it does not change the fact that all of the manually specified WDM inputs / outputs within windows are factory reset.

This is a huge problem when you’ve got many different WDM inputs / outputs specified within streamdeck, sound mixer, applications, games. EVERYTHING needs to be changed. And this happened to me TWICE today.

[atkAudioUser]

Are these Windows per-application input/output settings?

[mmotti]

Are these Windows per-application input/output settings?

Yes. It’s like the entire audio chain gets recreated when whatever happens, happens. So any preferences made within windows or applications that sit on top of windows get reset to system defaults.

Presumably because the referenced WDM audio devices no longer exist when they’ve been recreated.

[atkAudioUser]

Tested this with RME UFX+. Indeed, just changing the device samplerate even from the RME driver panel itself seems to "trash" the Windows per-app mixer io settings. The change of samplerate is probably related to this issue #51 But once set e.g. in PluginHost2, the samplerate stays persistent between OBS sessions at least in version 0.34.3.

[mmotti]

Ok so do I take from this then that there was a problem in the previous version of the plugin that didn’t respect the set sample rate, and that for whatever reason updating today to the most recent release could have amplified this problem somehow?

And that from the current version onwards the sample rate should be respected and not altered?

Does this also not point to some level of negotiation issue with the asio driver? For example if Gig Performer is fired up first and that locks the sample rate to 48k, then OBS launches with the incorrect sample rate, how does the plugin not negotiate with what should be the locked sample rate?

As far as I understand, that’s how every other application I’ve used has worked; especially when single speed in the RME usb settings is unchecked. It usually takes the first asio hook’s sample rate and locks it at that, no?

[atkAudioUser]

The plugin is a bit simpler, and does not communicate directly with device drivers. It uses JUCE framework. But it basically just asks whatever samplerate and buffersize was previously used, and accepts whatever the framework and driver returns. The driver may accept setting changes even when other clients/software are connected.

[mmotti]

Yeah this is just not stable for me.

I installed it again, added my configuration in and made sure that it correctly set to 48K / 256 to match the RME USB driver settings / Gig Performer.

Started OK initially - Routing as expected.

You can see in the above that initially things are routing as expected (in particular, Spotify).

After a few times of closing / opening OBS whilst Spotify was actively playing in the background, I heard the jackhammer sounds again which did subside after around 5 seconds however it knocked Spotify off of the dedicated route for Sound Mixer and defaulted back to system output.

This was not visually represented within Windows Sound Mixer; it still pointed to ADAT 3+4 output. The issue was not resolved until I restarted Spotify.

--

This behaviour however has happened before with the atkAudio plugin. Thankfully this time it didn't reset all of the WDM devices (and associated routing settings etc). But it still proves to not be stable enough to use.

--

Launching OBS with atkAudio plugin enabled causes major audible audio hitches for a period until it has fully initialised at the bare minimum. It can also break the WDM specified outputs within sound mixer (as pictured above), or break the sound chain completely and cause the WDM devices to all be fully re-initialised again with new GUIDs etc which means any existing settings are reset to default.

[atkAudioUser]

https://github.com/atkAudio/PluginForObsRelease/releases/tag/0.34.4 you can try this pre-release. At least with UFX+, Spotify doesn't drop on OBS start where the plugin uses RME via ASIO. All changes are internal, so it should not require any action on user side. It does not attempt apply any settings, and just opens device with the current samplerate/buffersize. E: https://github.com/atkAudio/PluginForObsRelease/releases/tag/0.34.5 JUCE upstream fixes here might also be related