macOS Round Trip Latency

I’ve mentioned this a few times before but I’ve now managed to implement some code to greatly improve the latency reporting on macOS.

After testing the reported and actual latencies for many devices and systems, there are two problems with the latencies reported on macOS:

  1. The actual latency is way higher than the reported latencies from the device
  2. The actual latency changes every time a device property changes (e.g. buffer size or sample rate)

I’ve drafted up some code using the input/now/output timestamps provided by CoreAudio which you can see here: CoreAudio: Changed latency reporting to update during audio callbac… · Tracktion/JUCE@d6f747b · GitHub

This seems to get the latency reported to within ~1ms of the measured latency for most devices.

This approach has the slight downside that the input and output latencies will jitter a bit but in my experience only by a few samples and the total is always the same. As you usually use input + output latencies this doesn’t really matter.


What are the JUCE teams thoughts on this? Is this likely to make it in to JUCE or can they think of a better approach?

5 Likes

See this too:

Yeah, it’s definitely a problem. I don’t think just adding the buffer size improves things much though as that won’t take in to effect the changes in latency when changing settings etc.
Using the timestamps from the CoreAudio callbacks seems to be the only way to get anywhere near the actual measured latency.

Fyi, I’m the author of RTL Utility - so we’ve used that to make measurements and can confirm that adding the buffer size fixed things for the listed interfaces across a range of settings. I haven’t received feedback from my user base to contradict this (though I wouldn’t consider that to be conclusive!).

2 Likes

I would just like to second what andrewj is saying at that we also found that the main issue with latency reporting with coreaudio devices was that the buffer size was not included in the reported latency.

I’m not familiar with what these timestamps you are using represent, so I don’t feel like I can really comment on your approach and whether it is valid ATM, my concerns would be though:

  • The latency doesn’t actually change after configuring and starting the device so why does it need updating?
  • How do clients get notified of the change in latency?
  • Does it include/represent all the latency components, such as systemic device I/O latency?

An example where we found the current latency reporting quite inaccurate was if using the UAD-2 Apollo QUAD, which for input latency coreaudio reports 292 samples for kAudioStreamPropertyLatency, which corresponds to the systemic input latency of the device e.g AD conversion/DSP etc and is constant irrespective of sample rate or buffer size. Output latency reported (kAudioStreamPropertyLatency) for the device is always 22 samples. AFAIR, these values are from memory but they are reasonably close. The kAudioDevicePropertySafetyOffset for the device was ~52 samples for both input and output and it also didn’t vary based on sample rate or buffer size.

So if we assume based on what andrewj and I have observed and the latency should be based on these properties:

  1. kAudioDevicePropertyLatency
  2. kAudioDevicePropertySafetyOffset
  3. kAudioStreamPropertyLatency
  4. kAudioDevicePropertyBufferFrameSize

Then at 64 samples:

Currently reported latency:

  • Input : 292(1) + 52(2) = 344
  • Output: 22(1) + 52(2) = 74
  • Total = 418 samples

Using all of the above latency components:

  • Input: 292(1) + 52(2) + 0(3) + 64(4) = 408
  • Output: 22(1) + 52(2) + 0(3) + 64(4) = 138
  • Total = 546 samples

At low buffer sizes the difference between these two values may not be too bad/noticable, but at 1024 samples:

Currently reported latency

  • Input: 292(1) + 52(2) = 344
  • Output: 22(1) + 52(2) = 74
  • Total = 418 samples

Using all of the above latency components

  • Input: 292(1) + 52(2) + 0(3) + 1024(4) = 1368
  • Output: 22(1) + 52(2) + 0(3) + 1024(4) = 1098
  • Total = 2466 samples

Which is quite a discrepancy.

So in response to:

  1. The actual latency is way higher than the reported latencies from the device.

I think the devices are reporting their latency correctly(well…the devices I tried anyway). Perhaps there is/was a misunderstanding as to what kAudioDevicePropertyLatency represented when the latency calculation was implemented.

  1. The actual latency changes every time a device property changes (e.g. buffer size or sample rate)

Yes it typically should, but as you can see from my example and from what I’ve seen it doesn’t due to the current latency calculation for coreaudio not including all the components of the latency.

1 Like

Just running into this myself. I’ve been patching my JUCE fork based on timbyr’s post and I’ll just mention for anyone reading that kAudioStreamPropertyLatency should be queried against the device’s AudioStream(s) not the device itself. kAudioStreamPropertyLatency has the same value as kAudioDevicePropertyLatency so it will appear to work but you’ll just be getting the device latency again. You can find an impl for getting the correct value from andrewj’s post here:

1 Like

I just reread this part of my post above and realise I meant kAudioDevicePropertyLatency rather than kAudioStreamPropertyLatency in that section. I think I got it correct later in the examples though.

1 Like