[SOLVED] Visual Studio debug build causes massive dropouts

#1

Hello everybody,

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:

trio_v0.1.jpg1280×839 208 KB

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?

Any advice is highly appreciated.

Greetings Matthias

#2

I think you can also debug with activated optimization:
https://msdn.microsoft.com/en-us/library/606cbtzs.aspx

And you can simply turn on optimization in the projucer for debug as well.

HTH

#3

Thank your for your response. I think I tried every possible option. But everytime I enable debugging, the problem occurs.

I even deactivated all effects of the synth and used only one BLIT-Oscillator, nothing helps.

#4

Have you tried building a debug version of the JUCE Host and using that to run your debug build?

Rail

#5

Yes, the problem also occurs in this case.

#6

https://msdn.microsoft.com/en-us/library/hh697468.aspx

#7

You should be able to use breakpoints and step through your code to debug it then.

Rail

#8

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.

#9

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.

#10

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 :slight_smile:

#11

I have practically no CPU load (about 3%) and no console printing stuff.

#12

Do you have a meter in your plugin? Are you seeing any metering from your synth?

Are you using an AudioProcessorGraph?

Have you checked what happens with the JUCE Demo plugin?

Rail

#13

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…

You aren’t stuck in a lock or anything ??

#14

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.

Thanks everybody for your time.

#15

My goodness!

You wold not believe what was the problem here:

I am using a BLIT Saw Oscillator, whose code I’ve got from musicdsp.org:

Sawtooth::Sawtooth(float sampleRate) : Oszillator(sampleRate) {
this->volume = 1.0f;
this->frequency = 440.0f;
this->fine = 0.0f;
this->p = 0.0f;      //current position
this->dp = 1.0f;     //change in postion per sample
this->leak = 0.995f; //leaky integrator
this->pmax = 0.5f * sampleRate / (frequency + this->fine);
this->dc = -0.498f / this->pmax;
this->lastValue = 0;

The process() method looks like

float Sawtooth::process() {

p += dp;

if(p < 0.0f)
{
    p = -p;
    dp = -dp;
}
else if(p > pmax)
{
    p = pmax + pmax - p;
    dp = -dp;
}

x = M_PI * p;

if(x < 0.00001f)
    x=0.00001f; //don't divide by 0

saw = leak * saw + dc + (float)sin(x)/(x);

if (saw > 1.0f)
    saw = lastValue;
else
    lastValue = saw;

return saw * this->volume;

}

What happens if iI leave the value of saw undefined? => NOISE and dropouts

Strange enough, that the problem only occurs under Windows and in debug mode.

Have a nice evening everybody!

#16

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…