Can anyone explain to me why this occurs in Debug build? No glitches in the Release build as expected. This is a standalone app. The Component does not share memory with the audio thread, however the graphics rendering is a bit inefficient at the moment.
I’m just curious as to how updates to a component on the message thread, would impact the audio thread in Debug? Or I have a latent bug to chase down.
Plenty of options here…
Some I can think of right now:
- DBG statements will use the system console and block for an unknown time
- processing without optimisation is too slow
- uninitialised variables (debug initialises variables for safety reasons)
to be continued…
Also the question, how are you sending updates to the UI?
Maybe a priority inversion?
(this is when the high priority audio thread has to wait for the low priority UI (message) thread)
Hey thanks for the tips. I don’t think it’s a priority inversion since I’m not calling any UI stuff in the audio thread (at least in my code, not sure about Juce debug). The UI component is a render of a wav file which is zoomed in within a Viewport. Despite caching a RectangleList of the waveform and only trashing the cache on zoom in/out, it appears I need to be a bit more clever there. That’ll probably speed things up in the message thread once I sort it out. As for the audio thread, there’s no connection to the UI, hence my confusion with hearing glitches when UI updates.