I noticed an issue with setting large audio buffer sizes on the Mac’s built-in input device. This is totally reproducible in the JUCE demo, freshly compiled from one of today’s snapshots:
On Mac, [build and] launch JUCE Demo.
Go to Demo -> Audio -> Audio Device Setup tab
Set the “input:” drop-down menu to one of the Mac’s Built-In inputs (name may vary per machine; on Mac Pro, try “Built-in Line Input”; on MacBook, try “Built-in Input”)
Set “audio buffer size” to a high value (try the max; in practice this problem should appear at around 5000 or so)
Result: an error dialog appears stating “Error when trying to open audio device!” + “Couldn’t change buffer size”. The “output” and “input” drop-downs are subsequently set to “<>”.
Basically what is going on is that the input device doesn’t actually support the buffer size being applied (whereas the output device does). In general I’ve noticed the highest buffer size supported for a built-in input device is around half of what is shown in the JUCE demo drop-down (in my experience, 3488-4640 sample frames).
Digging through the JUCE CoreAudio implementation (juce_Mac_CoreAudio.cpp), I noticed the buffer size list is generated as a hard-coded range of 32 to 8160 sample frames, in increments of 32 (see CoreAudioInternal::updateDetailsFromDevice()). This is applied to the JUCE AudioIODevice, which is a singular composite device comprised of the selected input and output hardware devices. (This also doesn’t accurately reflect some devices’ full ranges; on my system the Built-in Output shows a range of 14 - 13824 in HALLab.)
When I step through the code, I see that each deviceID is being queried for buffer size range, and the range is returned is consistent with what HALLab shows. However, it seems the list associated with the AudioIODevice is the full range available to the output device.
It seems that what JUCE should do is restrict the buffer size list to the range supported by both input and output devices (ie the subset of intersecting values), no?