Can't hear audio in "Processing audio input" tutorial and can't use printf

I’m trying to complete the Processing audio input tutorial. It’s my first one that involves audio. I can’t hear any audio when I’m using my laptop’s built in mic/speakers, nor headphones/external mic. I tested on Audacity to make sure the mic was working.

When I run from Visual Studio 2022 in either debug mode or without the debugger, no audio plays. I set a breakpoint in the for loop of getNextAudioBlock and saw that both the inBuffer and outBuffer pointers are 0, and their contents at any sample index are also zero.

The debugger reliably stops at this breakpoint in the for loop when I continue, suggesting that the code is reaching this point. However, when I put a printf line in the for loop (adding brackets) I can’t find that output anywhere, again either in debug mode or not. Not sure if this is just my greenness with C++ (are you allowed to print from a .h file?)

Also concerning, when I run normally, the debug output displays The program '[29500] ProcessingAudioInputTutorial.exe' has exited with code 0 (0x0). even though the window is still open and I can move the slider. When I X out of the window, nothing prints in this output display.

There’s no error messages or codes. I have no idea how to fix this.

Replace printf with Juce’s DBG and see if you come any further.

1 Like

This should work because for Windows GUI applications, the output of printf and std::cout/err doesn’t by default go anywhere where it could be seen. The Juce DBG macro uses the Windows OutputDebugString function instead, so the output can be seen in the Visual Studio process output panel.

1 Like

Thank you! I’ll look into how JUCE handles stdout in a bit. I found another post that’s relevant here.

I finally realized that the processing multiplies the output by the slider level. Since the slider is capped at 0.25 (and by default starts at 0), the volume gets significantly reduced. This meant I had to speak at a louder volume than I normally would to be able to hear the output above my own internal voice - or tap loudly on my laptop’s frame when using the internal mic. When the slider is between 0 and 0.1, I can hear basically nothing because the volume of the audio is so low.

As a suggestion for this tutorial, my expectations were that the volume of the original audio would remain constant while the amount of white noise added would be variable based on the setting of the slider. Either changing the explanation of the tutorial to be more clear or adjusting the code to match that description would help greatly.

Current description:

The demo project modulates an incoming signal with white noise. The level of the white noise can be changed which affects the level of the overall output. The result is a very “fuzzy” version of the input signal.

Currently, the level affects the volume of the output altogether, so the slider is really a volume slider. The volume of the white noise is actually constant, relative to the volume of the output.

Current processing line:

for (auto sample = 0; sample < bufferToFill.numSamples; ++sample)
    outBuffer[sample] = inBuffer[sample] * random.nextFloat() * level;

Suggestion:

for (auto sample = 0; sample < bufferToFill.numSamples; ++sample)
{
    // manipulate the floating point to fall between [-1,1]
    auto noise = (random.nextFloat() * 2) - 1;
    outBuffer[sample] = inBuffer[sample] + (noise * level);
}

[Edit: not meant for use in processBlock / audio thread!]

I once added this for tests with noise, probably based on online discussions:

void fillVectorWithNoise (float* vector, const int numSamples)
{
    std::random_device rd {};
    std::mt19937 gen { rd () };

    std::normal_distribution <float> d { 0.0f, 0.4f };

    for (auto i = 0; i < numSamples; ++i)
        vector[i] = d (gen);
};

Maybe this can help in any way? Not a uniform, but a normal distrubution (Gauss).
A filled vector like this would have to be mixed with the input of course.
(my habit is to think in vector operations/functions)

I would not use std::random_device in the audio thread…It can take a long time to construct/use that. Also, the Mersenne Twister random generator is relatively slow and is probably overkill for just generating white noise.

1 Like

Did I miss something like the audio thread? If so, sorry!

In that case, my example is of course meant for other applications! I added that in my reply :slight_smile:

I did mention I may use it for tests :wink: