There seems to be a bug in the WASAPIAudioIODevice. It returns latencies that are smaller than the current block size, which is impossible (normally they are higher) - i.e. latencyIn & latencyOut variables seem not to be properly computed.
Hmm… But it takes the number that the device provides, and adds the block size! The only way it could be lower than the block size would be if the device was reporting a negative latency… My test device doesn’t do that, but maybe you could check what yours returns in juce_win32_WASAPI.cpp, line 214?
but the thing is that although the “real” block size (as shown in the preferences) here is 2048 samples (and that’s really the size of the audio callback buffer!), you’re using the variable outputDevice->actualBufferSize (which was 512 here) in this line:
not sure, but shouldn’t this line rather be (btw, why are you adding outputDevice->minBufferSize?):
I suggest switching to 2048 samples block size, and you’ll probably get just the same results as I do.
Yes, I think you’re right about that… Can’t remember why I added minBufferSize, but it was probably just an attempt to fix the fact that the numbers were coming out smaller than what I was actually measuring… But since like you say, I was clearly just using the wrong block size, that would explain it! Thanks!