How DAWs handle if the excecution time of processblock is longer than time between processblock calls

Audio Plugins
1

I’ve been breaking my head on this one for several days now:

I am trying to make an arpeggiator. I get the midimessages in my processblock, process them and then put a midiBuffer back into the midimessages.

In Ableton it works like a charm, no problem there. In FL Studio however, sometimes output midimessages are dropped. To check if my processing is not too intensive i logged if there are times where the time between processblockcalls is less than the excecution time of that processblock. In ableton this never happens but in FL Studio this happens +/- 1/500 times.

So my questions are:
What happens if the excecution time of the processblock is bigger than the time between that and the next processblock? Are the midimessages and audiobuffer of that first processblock ignored?

Another thought I had is that maybe the demo version of FL studio has some processlimitations, my play-needle for example looks stuttery, could this be solved by buying FL Studio?

FYI: I know the numSamples in FL Studio is not fixed, I have also the problem if the numsamples is high that processblock (212) while buffers with a samplesize of 1 have no problem processing in time.

Thank you in advance, really stuck here,
Kind Regards,
Ambroos

2

It’s not really defined what will happen if the audio callback (processBlock in Juce plugins) takes longer than the audio buffer’s duration it is processing but the usual symptom is audio stuttering. With MIDI, I’d expect MIDI messages to be missed.

What are you doing in your processBlock code?

In addition to your own processing code doing too much work, at least the following can cause CPU spikes :

  • Allocating/deallocating memory
  • Printing to console/debug out (this is an annoying one as printing debugging messages is sometimes needed and the printing itself can cause additional problems on top of the existing ones)
  • Locking/unlocking mutexes
  • File I/O
3

Hello,

Thank you for your answer!

My problem is resolved. It was indeed my debugging code that was the problem. When I simplified my debugging code to paste here my problem was gone, now the excecution time is negligible compared to the buffers duration. I’m not sure what the problem was (I didn’t log the timings of the processblocks where i wrote to the logger) but I guess that does not matter anymore :slightly_smiling_face:

I do use some vectors that are CPU expensive and I lock/unlock mutexes multiple times, but didn’t have a problem with this before CPU-usagewise, I checked reguraly during development.

Got into the rabbit hole because the Microsoft Visual Studio Profiler said that some processing functions of mine were CPU intensive and the debugging once not. Learned my lesson not to trust the Profiler too much in the future.

Once again, thanks for the reply and have a nice day!

4

If your debug code was writing to disk or even to console, it may involve I/O wait time which some profilers will exclude from CPU usage. VTune depending on configuration will show them separately. To complicated it a bit more, some I/O wait primitives will involve both spin-time (CPU usage) and wait-time.

1 Like