Juce Synthesiser heap allocates in audio thread?

General JUCE discussion
1

Found this curious bit in the Juce Synthesiser code, in the findVoiceToSteal method :

Array<SynthesiserVoice*> usableVoices;
usableVoices.ensureStorageAllocated (voices.size());

Isn’t that going to cause a heap allocation in code that runs in the audio thread?
It could of course be argued that if a voice has to be stolen, there’s a likelihood some kind of audio glitch is going to happen anyway and the allocation potentially causing a glitch isn’t going to matter much in addition.

However, couldn’t this be fixed by just having the usableVoices array as a member variable of the Synthesiser class?

3 Likes
2

Looks like MPESynthesiser::findVoiceToSteal uses the same pattern…

1 Like
3

OK there is a fix for this in our review pipeline. Thanks for reporting.

3 Likes
4

This is now fixed with commit 87d5197 on the develop branch.

4 Likes
5

Nice one, thanks Fabian!

1 Like
6

Hey guys, just stumbled on this thing too.

I might be mistaken, but should line 205 of juce_MPESynthesiser.cpp be:

usableVoicesToStealArray.clearQuick();

instead of clear()? It seems like clear deallocates and also undoes the preallocating in ensureStorageAllocated we do when adding voices.

The same thing happens in juce_Synthesiser.cpp :).

Edit:

While we’re here, also wondering if the sorting should happen after all the voices are added.

2 Likes
7

Was playing with the realtime sanitizer a bit today and noticed that there is also some juce::array allocating going on around the note management:
juce::MPEInstrument::noteOn(int, int, juce::MPEValue) juce_MPEInstrument.cpp:377

Adding a note to the array and again using clear() in MPEInstrument::releaseAllNotes()

1 Like