Connection issue with obscure VST host (Buzz) and Hyper-V VM (and possible fix?)

[themarcnet]

Hello.

I decided to try out AudioGridder before using certain VST's that I am planning to purchase, but also have license restrictions. The idea is that if I can back up the VM Image, then I won't use up another license in the event that my machine dies, or that I decide to sell it and upgrade.

I am using Buzz for the VST host (Jeskola Buzz - http://jeskola.net/buzz/ , if you want to know) . This is probably more of an obscure audio app than you are used to, so I recognise that support for this on your side, is in the range of limited to none. Also something to note, is that the version of buzz I am using is 32-bit, and will launch a 64-bit process to handle 64-bit VSTs, including VST3s

So I load the VST into Buzz, Buzz loads it fine, but cannot connect to the AudioGridder server running on the VM. I have checked all network issues, and disabled the firewall running on the VM. I have also had limited success with connecting using Reaper - (I say limited, but it disconnects after a minute or so - I have not investigated this as much as the issue with Buzz, as I rarely use Reaper to create music. I use mainly Buzz for that purpose)

With Buzz, I get the following:

As you can see, the VM is listed - twice (The magenta to censor the IP info, with both IPV6 and IPV4, the IP address is correct), but no VSTs listed (yes, the VM has a single VST installed correctly - Reaper, when it was working, correctly showed the installed VST)

I've not posted the AudioGridder server logs, but I believe there is no need since I'm fairly sure the server is behaving correctly, and it's the client at fault (if it is a fault - for want of a better word) here.

Looking at the AudioGridder client logs ( example here -> https://pastebin.com/JanVUZnk ) it seems that:

- A connection is successfully made :  (init: channelsIn=0 channelsOut=64 channelsSC=0 rate=48000 samplesPerBlock=1024 doublePrecission=0)
 - A few tray connection failures occur (the tray monitor does appear, 
 - A reconnect is requested (init: paramater change, requesting reconnect)
 - Reconnect successful, but this time has no output channels ( init: channelsIn=0 channelsOut=0 channelsSC=0 rate=48000 samplesPerBlock=256 )
 - Infinite reconnect loop
 -  (re)connecting...,  (re)connecting...,  (re)connecting... ....

As Buzz is (probably - this is my guess) not a supported VST host for AudioGridder, I decided to debug and investigate myself. I built dependencies and AudioGridder with VisualStudio 2019 (yay CMake!), added some OutputDebugStringA calls to juce_VST3_Wrapper.cpp, added a message box to PluginProcessor::prepareToPlay (so I could attach the debugger before AudioGridder does its stuff), and deployed and attached. This is what I saw (according to the debug output I added)

• Client::init is called (presumably to start the client thread)

• activateBus is called 63 times where type=0, dir=1 (output), index= 0 - 62, state = 1 (ON)

• activateBus is called another 2 times where type=1, dir=0 then 1, index= 0, state = 1 (ON)

• setupProcessing is called with True

• setupProcessing is called with False

• activateBus is called 63 times where type=0, dir=1 (output), index= 0 - 62, state = 0 (OFF)

• activateBus is called another 2 times where type=1, dir=0 then 1, index= 0, state = 0 (OFF)

• setActive is called with state = 0

• setActive is then called with state = 1

• At this point, the client thread calls Init with: channelsIn:0, channelsOut:0, m_channelsSC: 0, rate:48000, samplesPerBlock:256

• activateBus is called 63 times where type=0, dir=1 (output), index= 0 - 62, state = 1 (ON)

• activateBus is called another 2 times where type=1, dir=0 then 1, index= 0, state = 1 (ON)

• setupProcessing is called with True

• Lots of 'processParameterChanges' calls

• Client, when it reconnects and calls init (no parameters), will refuse to because its 'm_channelsOut' is still zero - it has not been updated of the new situation.

This looks very much like a timing issue, where the Client thread has been re-initialised at the wrong time, and/or has not been re-initialised at the correct time....

With this, I had a thought - "What happens if 'setupProcessing' calls setActive(true)?" ...

So I went about and made this change, tested it, and SUCCESS!, The Buzz VST host now communicates with the VM, and correctly shows the VM with the VST installed:

So this is the "fix" (with my debug strings removed) to juce_VST3_Wrapper.cpp:

tresult PLUGIN_API setProcessing (TBool state) override
    {
        if(!state)
        {
            getPluginInstance().reset();
        }
        else
        {
            //Set active, in case channel information has not yet been pushed to the
            //client thread
            setActive(state);
        }

        return kResultTrue;
    } 

For clarity, I appreciate that I'm not very familiar with the inner workings of AudioGridder, and that I have only looked and debugged it for a few days on and off.

With that, I also appreciate that the above "fix" (I use the term loosely at this stage) may have unseen side-effects, and could possibly be seen as "This guy does not know what he's talking about and has clearly hacked the code without knowing what he's doing".

But it worked for me :) - At least it connects and remains connected to the server running on the VM.... There are further issues that I need to investigate, where launching the VST UI will crash. But that's a different issue to connecting, so I'll leave that as a future update (could also be a ffmpeg issue, where I've not built the correct version / options / configuration/ etc)

Thanks for your time

Mark

[themarcnet]

Forgot to add the logs for when it successfully connected -> https://pastebin.com/3q6ZKL1d

Also, when it had successfully connected, I was able to tell Buzz to play a few notes using the default preset for the VST and audio was successfully generated

[themarcnet]

I also forgot to mention (I keep forgetting the most important info!) that I was originally using release 1.2.0 I had then got the source of the 1.2.0 tag and built it myself, and this was the debug version that I was using above. I had also deployed the debug version of the server to the VM during my testing.

It turns out that reverting the server back to the original release version of 1.2.0, but keeping my fixed" debug version of 1.2.0 of the client, means that the VST UI now also appears correctly - probably meaning that I had either not logged into the VM, or had not correctly copied the dependencies to the VM.

Anyway, I hope this information (and there is probably too much of it) is useful to someone. Feel free to ask any questions, if I have missed anything.

Mark