Connection issue with obscure VST host (Buzz) and Hyper-V VM (and possible fix?) #1367
Replies: 2 comments
-
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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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:
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:
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
Beta Was this translation helpful? Give feedback.
All reactions