If the preferredSize argument is not the same as the maxSize argument, then the maxSize will not always be added to the bufferSizes member.
It looks as though in this loop:
for (int i = jmax ((int) (minSize + 15) & ~15, (int) granularity); i < jmin (6400, (int) maxSize); i += granularity)
bufferSizes.addIfNotAlreadyThere (granularity * (i / granularity));
that the less than operator excludes the maxSize.
The result of this is that when opening an audio device it’s not possible to choose the max buffer size, as the max buffer size isn’t present in the bufferSizes member.
Let me know if I can provide any further information.
Totally respect this code is old and probably well exercised but I agree that the issue reported here is a bug. I think it’s slightly more subtle though, it only happens for devices that report a positive granularity. Where a negative granularity means the buffer sizes increase in powers of two. I also suspect few people would notice this issue as they would have to be aware of the maximum buffer size of the device and spot that it wasn’t in the list.
I think there are potentially a few other questionable things about this code too, but it should at least be <= for testing the maximum buffer size.
This is actually an issue for us as we have some tools for testing devices and drivers written in JUCE that can’t switch to the maximum buffer size.
And @ed95 - if you’re wondering why this wasn’t flagged with the recent change which allowed a max buffer size of 32768, well that’s because that change was to support an RME device, and RME devices only allow buffer size to be changed from their own driver control panel (they respond with min, max & preferred all as equal to the current buffer size).
