Brusfri combined with some other plugins maximizing/killing output


EDIT: Below we’ve narrowed down the issue to a combination of Brusfri and and some other plugins (namely Crave EQ and Ozone 8 Elements in my brief testing Brusfri being the common denominator.

I'm currently using the Trial version and am experiencing a weird issue.

I’m using Voicemeeter Banana’s ASIO Insert driver in GP.

I set up a few plugins and everything works great. If I close GP and reopen it I hear a little pop then the output is maxed out.

It doesn’t resolve until I go to Options -> Audio Setup -> and click “Reset device” and apply settings. Everything works fine until I close and restart GP and it happens again. Every time.

Any help provided would be fantastic! I don’t have this issue using other hosts but I prefer GP’s feature set so I’m hoping to fix this and purchase.


What is the purpose of using Voicemeeter Banana within GigPerformer?


I’m using it for streaming on Twitch. I have my audio interface configured through Voicemeeter which allows me to send the resulting output to virtual WDM devices for use in Discord and OBS etc. I’m using GP basically as a VST host that has OSC support.


I am wondering, what GigPerformer is responsible for that issue.

Do you have a multiclient asio driver installed?

What samplerate are you using in GigPerformer and how many samples buffer?


Nothing else is using the Voicemeeter Insert ASIO driver. My entire workflow from interface onward is set to 44100/512.

Like I said everything works fine until restarting GP. I would think it’s something to do with initialization of the ASIO driver selected. Very slight possibility it’s related to the trial popup that comes up when starting GP but I’m not going to purchase just to test the theory.


Hmmm. Very strange. What happens if you install ASIO4ALL driver and use it instead?


I don’t know. ASIO4ALL may or may not work but I want to stick with a real ASIO workflow as much as possible.


I would suggest installing and trying it regardless. It is not going to take over anything. It becomes another driver that you can use if you want to, but can always use the native driver.
ASIO4ALL is known to sometimes “fix” some strange registry issues with other drivers after installation that’s why I am suggesting it. It will not break anything and it can be uninstalled after all.

The purpose of the test is to see if the issue is with the driver.


Ok tested. It happens with ASIO4ALL selected as the ASIO driver in GP as well. This leads me to think perhaps it’s a Windows 10 October update issue perhaps? This is a fairly clean Windows 10 install. I formatted last week.

I can also make it happen by just loading another save file in GP so starting the app isn’t the problem.


Btw… no need to go to options. If you want to restart the audio device you can double click the Panic button in the top right. Single click resets MIDI double resets both - MIDI and Audio.

The only thing that comes to mind has already been mentioned here and you confirmed that’s not the case (the possibility of another application using the driver).

Make sure that your SYSTEM audio device is not the one you use with GP. IT may be interfering for some reason although I use it that way all the time without problems.


Looks like it’s somehow related to my Crave EQ plugin. If I simply bypass and unbypass that one plugin in my workflow it temporarily fixes until I close and reopen GP. So strange.
BTW double clicking the Panic button doesn’t fix.


Ah… yes. If your plugin is misbehaving double clicking on the PANIC button will not do anything.

Opening the options and then clicking “Apply” later will actually remove and reload / re-initialize all your plugins which explains what that works.

Unfortunately it seems that this has nothing to do with GP. I would encourage you to contact the plugin manufacturer.


Ok after more playing around it is some bizarre combination of Brusfri plugin and Crave EQ. I can reproduce by simply adding brusfri and connecting it to Crave EQ and restarting GP. If I remove or bypass either plugin the issue vanishes.


Right. Definitely the plugins… Your title is somewhat misleading now that we discovered it’s the plugins so maybe consider changing the topic title to Brusfri & Crave EQ plugins maximizing/killing output… just in case someone else is searching for it or has a similar problem.


Ok I have edited the topic. To be clear I’ve used the same exact combo of plugins in another VST host and Reaper without issue. I’m inclined to just replace one of the plugins as I have my doubts about getting this fixed anytime soon.


Another data point. I think it’s just the Brusfri plugin causing issues when mixed with some other plugins because I replaced Crave with another EQ and still get the issue.


Unfortunately that doesn’t prove that much. We are deeply leveraging the VST API. Some hosts don’t exercise plugins as much as we do and so don’t support everything that can be done by a VST.

Consequently, when plugin developers implement their plugins and test them with a few hosts and the plugins work, they declare they’re “done”.

You should report the issue to the plugin developer. It has been our experience that most plugin developers are happy to work with us to figure out what’s wrong and fix it.


Ok I will contact the Brusfri dev.


I heard back from the Brusfri dev. This is what he had to say about the issue

“We’ve probably found the issue; GP is reporting the wrong sample rate (we get 0 Hz) inside the processing callback which made all filters blow up a bit… We’ve made a workaround for that and will update the plugin in a near future.”


When a plugin is loaded, Gig Performer tells the plugin what is the sample rate as part of the plugin initialization. The sample rate doesn’t change from one call to another of a process block so I’m not sure why a plugin would be querying the sample rate during process block callback. That’s a waste of CPU cycles!