Memory leakage in simple console application

General JUCE discussion
1

Following this thread I have created a simple console application to process sound (send input with high gain to the output). However, I am getting memory leakage that I can not resolve where it comes from. If I comment out the instance my custom class, the problem disappears.

The leakage is always 32 bytes long, regardless of the complexity of my audio class. I know it is not that crucial but I would like to understand why and when it happens.
I use Windows 10 with Visual Studio 2017.

Any help is much appreciated.

Here is the main function and the class I made:

Main.cpp

#include “…/JuceLibraryCode/JuceHeader.h”
#include “audioclass.h”

int main (int argc, char* argv)
{
initialiseJuce_GUI();
AudioClass ac; // The custom class I have made
DBG(“press ‘Q’ to stop”);
while (auto c = getchar())
{
if (c == ‘q’ || c == ‘Q’)
{
break;
}
}
shutdownJuce_GUI();
return 0;
}

audioclass.h

#pragma once
#include “…/JuceLibraryCode/JuceHeader.h”

class AudioClass : public AudioIODeviceCallback
{
public:
AudioDeviceManager deviceManager;
AudioClass()
{
DBG(“AudioClass”);
deviceManager.initialise(2, 2, nullptr, true);
deviceManager.addAudioCallback(this);
}

~AudioClass()
{
DBG(“~AudioClass”);
deviceManager.removeAudioCallback(this);
}

void audioDeviceIOCallback(const float** inputChannelData, int numInputChannels, float** outputChannelData, int numOutputChannels, int numSamples)
{
for (int channi = 0; channi < numOutputChannels; channi++)
{
for (int i = 0; i < numSamples; i++)
{
outputChannelData[channi][i] = inputChannelData[channi][i] * 1000;
}
}
}

void audioDeviceAboutToStart(AudioIODevice* device)
{
DBG("audioDeviceAboutToStart:\nDevice : " << device->getName() << "\nSampleRate : " << device->getCurrentSampleRate() << "\nBufferSize : " << device->getCurrentBufferSizeSamples());
}

void audioDeviceStopped()
{
DBG(“audioDeviceStopped”);
}
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR(AudioClass)
};

1 Like
2

It’s probably fine to leave as it is but slightly annoying to see it in the Visual Studio output. (It’s probably the issue where some Windows data structures are left undeleted by JUCE at the end of the program’s execution. I’ve been seeing that same thing in my JUCE projects forever.)

If you see asserts from the JUCE memory leak detectors, that’s a more serious thing which you should attempt to fix.

3

It might have to do, that the message queue is never run. Jules explains it here:

Following Xenakios: this one is save to ignore.