keyboardState/Component audio dropouts when minimizing

I have a problem with the keyboard component.
using win xp 32 and the tip from some weeks ago.
also reproducable in the juce demo (everything release build)
no matter if asio or direct sound and with 2560 samples latency.

when i play audio (for example with the file playback screen in the demo) and minimize/restore the demo window and simultaneously show some notes via the MidiKeyboardComponent (doesn’t matter if from external keyboard or internally generated) the audio has a short dropout/stutter.
when i remove the call to

keyboardState.processNextMidiBuffer (incomingMidi, 0, bufferToFill.numSamples, true);

from the getNextAudioBlock() routine the resize happens without dropouts.

the dropouts happen even when the KeyboardComponent isn’t visible.
the CPU load stays very low (0-2%) while doing so.
I can do much higher CPU hungry operations in paint() routines going up to 40% CPU without dropouts.
So I’m rather clueless at the moment. must be something different…

any tips?


so far I isolated the problem to the

calls inside the functions

void MidiKeyboardComponent::handleNoteOn (MidiKeyboardState*, int /*midiChannel*/, int /*midiNoteNumber*/, float /*velocity*/) void MidiKeyboardComponent::handleNoteOff (MidiKeyboardState*, int /*midiChannel*/, int /*midiNoteNumber*/)
when I remove the triggerAsyncUpdate() functions the dropouts are gone.

removing the code inside the

method has no effect… still dropouts.

I’m allready running the GUI thread at lower priority and the process on high

void initialise (const String& commandLine) { Process::setPriority(Process::HighPriority); Thread::setCurrentThreadPriority (3); ...

I’m going to investigate further…


hmmm, seems others had this problem, too.
now that i know it has todo with the asyncUpdater i found some forum posts:

Audio “hickups” when events occur…
AsyncUpdater which don’t malloc

seems i have to rewrite some parts of the keyboard component…
or is there a solution for the triggerAsyncUpdate() call in audio threads yet?


okay i kind of solved my problem with a workaround.
I derived my CustomMidiKeyboard Component from MidiKeyboardComponent and have overwritten the following methods:

/** overriding the parents handleNoteOn function because it uses a triggerAsyncUpdate() function which causes audio glitches on window minimizing/restoring
void handleNoteOn (MidiKeyboardState*, int /*midiChannel*/, int /*midiNoteNumber*/, float /*velocity*/)
/** overriding the parents handleNoteOff function because it uses a triggerAsyncUpdate() function which causes audio glitches on window minimizing/restoring
void handleNoteOff (MidiKeyboardState*, int /*midiChannel*/, int /*midiNoteNumber*/)

/** same as MidiKeyboardComponent::handleAsyncUpdate() but used with the repaint timer*/
void handleRepaintCall()

the handleRepaintCall() method is called by a timer now, the audio glitches are gone.


It is well known that PostMessage (used by JUCE on Windows for sending the ASyncUpdater’s message) can take longer when resizing windows - and even if you’re not resizing Windows I bet it sometimes takes longer to return. JUCE shouldn’t rely on this function, but rather implement something itself. I wrote about this here: . Jules didn’t reply so far.

Thanks - yes, the keyboard comp should probably use a timer instead of an async message, I’ll tweak that for you…