Plug memory leak calling setStateInformation() on hosted VST3 #484
Conversation
Repeatedly switching audio on, then off in a standard Audio/Midi Settings dialog would cause an assert failure, which I tracked to AudioIODevice::getAvailableBufferSizes() sometimes returning duplicate results.
|
For the second commit, what platform were you using when you spotted duplicates? |
My mistake--that second commit wasn't meant to be part of the original memory leak fix. It's a separate issue. I committed the change to my own fork because I use GitHub to propagate among different development PCs and Macs. It didn't occur to me that it would come up for you as part of the open PR--sorry about that. I don't consider this change definitive in any way, but the duplicates do occur, so probably ought to be investigated. To answer your question, I saw this on Windows 10 64-bit, when I opened a standard Audio Device Setup dialog and ticked, then un-ticked the box for input channels 1&2. For some reason the block size 128 was enumerated twice. |
This is only needed for the Unify application. Eventually I hope to have a clean work-around which will not require any change to JUCE code.
This is probably only required to enable use of an older version of the AAX SDK.
Making the params member public allows my version of the Generic Audio Processor Editor to keep working.
Without this change, I don't believe there is any way to allow plug-in parameter names to be updated by the plug-in.
RIFF chunks are supposed to be padded to even length, but some WAV files feature an odd-length "data" chunk. These changes make the WAV reader code tolerant to this.
See my JUCE Forum post https://forum.juce.com/t/memory-leak-calling-setstateinformation-on-hosted-vst3-plugin/31660, and test/demo project https://github.com/getdunne/juce-wrapper. I think the leak is caused by the
ComSmartPtr<Steinberg::MemoryStream>object getting initialized with a reference count of 2 here, when it should be just 1.