currently I am developing a simple Synthesizer with JUCE. Until now I’ve done almost all coding under macOS and XCode. As host app I am using Logic Pro X. Everything works like a charm, no matter if with or without debugging enabled.
Here is a screenshot for those who are interested:
A few days ago I’ve ordered a Windows 10 machine, to be able to compile the Plugin as a VST for Windows. I am using Visual Studio 2015 Update 3 for compiling and have a good I7 machine with decent audio hardware, having all latest drivers and updates installed.
As long as I just compile a release build and run the plugin in Reaper, Ableton or the Plugin Host Demo,
everything works fine. But if I compile the debug build (with optimizations disabled) and run it,
the audio stops working almost immediately after pressing a key on the keyboard.
The problem occurs with all audio devices I own, which are a Focusrite Scarlett 6i6, a Presonus StudioLive 16.0.2 and a ZOOM U-24.
This way I am not able to debug the plugin under Windows, which is very disappointing.
Does anybody have a suggestion for me or had this problem already? Maybe we need to dig into the code to spot the problem?
Well, I actually can debug, but that doesn’t help. There’s nothing to debug. The processBlock method is being called regularly just as in Release mode. Only the audio output drops without any obvious reason.
How is the CPU meter reading?
It sounds that your plugin with optimization is able to deliver the blocks in time. But without optimization it is simply not fast enough. The audio thread will not wait for your processBlock method to finish (or more precise the audio driver is not waiting for your audio thread).
So that’s actually nothing the debugger can help you IMHO.
Slam the profiler on the debug build and see if you can see what’s chewing all the CPU. Also, check you’ve not got any stuff printing to console in debug mode from your processBlock - that can bring things quickly to a halt
Curious… Try increasing the buffer size on your sound card? You could try turning optimisation on in debug build which would at least show whether it was CPU or some other debug build related issue…Ah - no you’ve done that already??
I think follow Rail’s advice, add/enable some metering. Possibly you could count the buffers per-second you are getting. But I’d definitely grab the profiler as well…
Ok, so far I reduced everything to the max. No FX, no modulation, no envelopes.
Now I have at least some voices playing, but still with a dropout at the trigger gate.
I am not using a Graph. Increasing the buffer size did not help either. I’m now going to implement some measuring and have a look what’s going on. Currently the problem seems to come from my oscillator code since the JUCE demo plugin runs fine in any case.
Ah - now here’s a thing. Mac seems to (someone correct me here) initialize your applications memory with zeros. Undefined variables don’t show up so frequently.
Microsoft do rather better for you, when debugging you get magic numbers in the memory which helps spot bugs…
here’s a list stolen from stack overflow…
0xABABABAB : Used by Microsoft’s HeapAlloc() to mark “no man’s land” guard bytes after allocated heap memory
0xABADCAFE : A startup to this value to initialize all free memory to catch errant pointers
0xBAADF00D : Used by Microsoft’s LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory
0xBADCAB1E : Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger
0xBEEFCACE : Used by Microsoft .NET as a magic number in resource files
0xCCCCCCCC : Used by Microsoft’s C++ debugging runtime library to mark uninitialised stack memory
0xCDCDCDCD : Used by Microsoft’s C++ debugging runtime library to mark uninitialised heap memory
0xDEADDEAD : A Microsoft Windows STOP Error code used when the user manually initiates the crash.
0xFDFDFDFD : Used by Microsoft’s C++ debugging heap to mark “no man’s land” guard bytes before and after allocated heap memory
0xFEEEFEEE : Used by Microsoft’s HeapFree() to mark freed heap memory
Anyway - maybe that explains why it shows up in Windows and only in debug builds…