This is somehow rare but it does happen and we were able to reproduce oddities in the following scenarios:
It seems that:
blockSizeMs (which is only used for wait interval). should be divided by number of retries?. (since the entire callback could be eaten by trying to get input not leaving time for the output process).
This also happens with Tracktion Waveform.
I apologize for ‘bumping’ this. but I guess some posts are lost. Since it’s not a show stopper I’ve yet to push the fix to SoundRadix JUCE hoping to save possible merge conflict for us 
Yes, this one slipped through - thanks! We’ve pushed a fix to develop here:
The mechanism of waiting for a few block sizes inside AudioIODeviceCombiner is useful as it’ll ensure that all the devices are in sync, so we don’t want to reduce the total wait time. However we can be a bit smarter about the wait intervals by using an exponential backoff as this will catch devices which only just miss filling the buffer without having to wait a full block size. We’ve also added a check for whether we’re waiting for input data but CoreAudio just isn’t providing any input channels as we can skip over the device without waiting in this case which will fix the issue of glitches when waiting for input permissions.
Thanks.
I’ve tested that on my unique setup that easily stutter due to failing USB audio driver.
It’s now not stuttering, but since the exponential change switching from a failing device (eg. AudioPluginDemo and AudioDeviceSelector takes a few seconds which I suspect it is due to exponential backoff.
So it seems for most use cases this will work well. with the exception above.
The total wait time in the backoff is limited to max (5ms, 5 buffers) (the same as it was previously), so this means that either something is going wrong in the code or something else is affecting it.
