CoreAudio device latencies are reported inconsistently with other audio device types

Hi all,

Based on test results from a few different audio interfaces on MacOSX, the results for getLatencyFromDevice() do not include the bufferSize and are therefore inconsistent with what is returned by other audio device types.

It seems to me that newBufferSize should be added to both inputLatency and outputLatency in juce_mac_CoreAudio.cpp - CoreAudioInternal::updateDetailsFromDevice().

Also, the current implementation ignores kAudioStreamPropertyLatency that myhrman called out on this thread. I’ve never seen it report anything other than 0, but it probably ought to be included.

Devices tested:

  • Steinberg UR22
  • In-built speaker & mic
  • Focusrite Scarlett 6i6
  • ZOOM TAC-2
1 Like

We also discovered that the coreaudio backend has latency reported that is inconsistent with at least the ASIO devices/backend. I can also confirm that adding the buffer size to the currently reported latency gives reasonably accurate roundtrip latency results with these devices at all supported sample rates and buffer size combinations:

  • UAD-2 QUAD Apollo
  • Focusrite Scarlett 2i2
  • Numark Scratch
  • Yamaha AG06

It was also accurate for the in-built devices when aggregated “manually” in system preferences but still reasonably inaccurate when the devices were aggregated by JUCE using the AudioIODeviceCombiner, but I think that is a separate issue.

JUCE currently only reports audio device I/O latency for coreaudio devices based on kAudioDevicePropertyLatency and kAudioDevicePropertySafetyOffset. There are other latency components that need to be included see https://stackoverflow.com/a/65728766 or some other examples on the internet (I won’t mention them directly as they may have licenses incompatible with JUCE etc).

This issue was considered to be “Critical” to fix in our software and so it is a bit surprising this issue has seemingly been around for so long.

1 Like