Audio buffer size problem

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:

  1. On Mac, [build and] launch JUCE Demo.

  2. Go to Demo -> Audio -> Audio Device Setup tab

  3. 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”)

  4. 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?

Were you just poking around trying to break it, or did you actually have a reason for wanting to use such a large buffer? I can’t think of any practical purpose for using anything greater than about 1024 samples on modern hardware, especially with coreaudio… Anything more than that would give you a big latency, but wouldn’t improve efficiency by any measurable amount.

(TBH I should probably reduce the maximum buffer size to about 2048…)

You got me fair and square, I was trying to break it! :wink:

Seriously though, why have those choices available if they’re not valid? It just leaves the door open for people like me to come along and apply wacky settings, then wonder why my devices get disconnected.

Apart from that, rather than throttling down to 2048 as you mention, why not have JUCE present the full range of buffer sizes common to both devices? A JUCE client / app developer could still filter the resulting list if desired. Just seems we should be able to utilize up to the max if we wanted. What if say, I was writing a consumer app meant to run on a slow or otherwise resource-drained machine, where latency wasn’t a concern, and I wanted the option to jack the buffer up as much as I want? Just sayin’. :slight_smile:

Fair point, it shouldn’t go that high - that’s an oversight that I’ll sort that out when I get a moment.

But honestly, there’s no piece of hardware (especially on mac) that would see any performance benefit from running more than 2048 samples. And in my experience, buffers over 1024 often actually decrease performance because many drivers have to start using extra memory buffers to cache your data, because there’s more of it than they can stream directly to their hardware buffer.

And I’d have thought that if you’re writing a consumer app (i.e. for dumb users who will drag things around without understanding what they’re doing) then you’d almost certainly NOT want to let them choose a large buffer size, because you’d inevitably get support calls from plonkers complaining that their audio has become “slow” or something.