I am using JUCE v6.1.3. on Windows 11.
When I select windows audio (low latency mode) the buffer size is only 480 samples.
On the other hand, if I select windows audio, I can select samples (144-2048) of various buffer sizes.
I was expecting a smaller audio buffer size by choosing windows audio (low latency mode) instead of windows audio.
What’s wrong?
Is it just a problem with my computer?
If memory serves me correctly this suggests the driver in question is using the WaveCyclic model as opposed to the WaveRT model.
I believe all WaveCyclic drivers will only have a single buffer size of 10 ms from the point of view of WASAPI (I may be speaking slightly out of place here, maybe others can correct me if so).
What this means is in the low latency mode I suspect you’re getting callbacks that more directly correlate with the WaveCyclic driver. Where-as with the other option you have more flexibility in terms of buffer sizes but ultimately you’re likely to get worse round trip latency as there is almost definitely an intermediate buffer that WASAPI is introducing in order to offer this flexibility. If you’re in exclusive mode in theory WASAPI can make this as optimum as possible (but still never better than the low latency mode), if it’s shared then the latency will also likely depend on other applications.
Obviously JUCE can’t do anything about this. The driver developers certainly could but I understand the work to be fairly significant. Possibly Microsoft could do something about it? 
I don’t know enough about the WaveCyclic model to know if that’s true though.
I should add that any half decent audio interface will likely have an ASIO driver which will allow you to access much lower buffer sizes if that helps at all?
