[Solved] Choppy audio on very basic audio application

General JUCE discussion
1

I have a very simple standalone plugin, which is compiled in debug conf on Windows7, however, the audio is superchoppy, although it depends on the sample rate chosen. Here’s my code, am I doing something wrong?

void OdinAudioProcessor::processBlock(AudioBuffer<float> &buffer, MidiBuffer &midiMessages) {
  for (int channel = 0; channel < totalNumInputChannels; ++channel) {
    auto *channelData = buffer.getWritePointer(channel);
    for (int sample = 0; sample < buffer.getNumSamples(); ++sample) {
      analog_osc[channel].update();
      channelData[sample] = analog_osc[channel].doOscillate() * 0.2f;
    }
  }
}

I’m pretty sure the oscillator itslef is working just fine.

2

you have one analog_osc instance for all channels, so the block meant for the next block is found on the next channel, making the period progress in a wrong way.

1 Like
3

Actually, I do have one for every channel, but I tried to boil the code down to the very basics for this post, I’ll fix the original post now!

4

In that case it points towards the oscillator. I don’t see anything wrong, except what you just fixed…

I don’t know that class, but I assume, doOscillate() returns the next value and advances the phase. What does update()?
What makes you sure, it works “just fine itself”?
Is the system in the clear, or is it under stress?
Is the life time persistent with the processor, or is the oscillator silently recreated on each call?

1 Like
5

Exactly, and update() will apply pitchshifting from the panel controls and calculates the wavetable increment.

I developed it in another application (RackAFX), and just now, I even looked at the waveform when printed into a file and visualized… All good.

The application is pretty much the only thing…

Yeah the oscs are members of the processor, so no recreation here.

I wondered if the debug config could take such a heavy toll on the application?
I’ll try compiling in release now.

Anyway, thanks for your answers Daniel :slight_smile:

6

compiling in release didn’t help (the process CPU% is somewhere at 1%, so yeah…)

I’ve also noticed that the sound is basically on for half a cycle and then off for another. These intervals are proportionate to the buffer size i choose, so my best bet is that I am still writing to the buffers incorrectly.

7

My code was fine all along, it was the audio driver. Gotta love linux-audio :neutral_face:

I was able to find a very specific combination of input/output involving the motherboard audio output which works.
If you’ll excuse me, I’m off to buying a linux compatible audio interface.

8

That is annoying, sorry for you.

At least you found the root cause.

1 Like