Troubleshooting Latency in DAW-like App

[simonhill-fr]

Hi, I’m working on a standalone DAW-like application, and I’m having an issue with audio latency : the “playback” latency (time between pressing the spacebar and sound coming out the speakers) is about 280ms !

Note that this only happens when an audio input is selected in the settings, if there is no input, the playback latency is ok.
Also, this is a lot less problematic with lower buffer sizes (almost no latency)

The latency values in samples reported by AudioIODevice::getInputLatencyInSamples and AudioIODevice::getOutputLatencyInSamples are the following (@ 44,1k, 2048 buffer):

• With no input selected in settings:
  • input: 0
  • output: 765 (17ms)
• With one input selected in settings
  • input: 4162 (94ms)
  • output: 4861 (110ms)

1. What’s going on ? Why does adding an input blow up both numbers like that ? And why would selecting an input add latency on playback ?
2. Also, why are none of these numbers consistent with the 280 ms I measured ? Assuming I could live with this latency, how am I supposed to compensate it ?
3. Ultimately, how could I get rid of this latency, where could it be coming from and how could I troubleshoot it ?

Thanks for reading, any help would be greatly appreciated

[stefhen]

Are you on Windows?
Are you using a proper audio interface or the built-in audio ports?

[yairadix]

How much latency do you get in the DAW of your choice? If it’s bad, once you troubleshoot that (depending on your platform might be by using ASIO4ALL on Windows, or switching to iPhone on Android, etc) you can try to see if you can achieve the same latency with JUCE.

[simonhill-fr]

I’m on macOS, I just did some first tests on windows and I don’t have the same issues. There is no playback latency difference between having an audio input selected or not, and the latency is much less at high buffers. I need to make some more precise measurements but numbers seem to add up a lot more. Looks like a mac problem then. I’m using a Bootcamp windows on a MBP with “Windows Audio” as a selected device

[simonhill-fr]

I’m on a macbook pro, and the latency in Ableton is totally different.

• The latencies shown in the Ableton audio preferences are 46ms for input and 64ms for output (2048 buffer @ 44,1k)
• Selecting an audio input in Ableton does not change the output latency

@yairadix

try to see if you can achieve the same latency with JUCE

What do you mean, what can I do to lower the latency with JUCE ?

[yairadix]

The device you’re on and the fact it works in Ableton is valuable information. I’d add which version/commit/fork of JUCE you’re using and whether it reproduces in JUCE’s own examples like its AudioSettingsDemo.

For example I’m also on an MBP and this doesn’t repro here:

Current audio device type: CoreAudio
Current audio device: "MacBook Pro Speakers"
Sample rate: 44100 Hz
Block size: 2048 samples
Output Latency: 174 samples
Input Latency: 114 samples

[simonhill-fr]

The app runs with version 6.1.4 of JUCE

As far as the latencies reported, they are the same in the AudioSettingsDemo (running on 6.1.5):

[yairadix]

And what is the situation with the very latest JUCE?
Also: which MBP are you testing on and version of macOS?

[simonhill-fr]

Same situation with the latest JUCE
I have a MacBook Pro (Retina, 13-inch, Early 2015) running Big Sur (11.6.8)

Also, I ran the AudioLatencyTest from the JUCE 7 DemoRunner, here are the results (2048 samples @ 44.1k). Does thats mean that the reported latency is off by 100 ms ?

[yairadix]

Here are the results for me. Measuring with both 2048 sample buffers and 16 samples on an M1 MBP’s built-in speaker and mics on macOS 12.5

Latest JUCE commit in develop branch 44183763359d680c:

SR’s juce7 branch 3a1768bdc6df38:

The difference comes from fixes we’ve made a while ago exactly for these kinds of issues for Pajam. It appears we’ve made some changes/fixes in modules/juce_audio_devices/native/juce_mac_CoreAudio.cpp.

Both branches seem wrong by about the same amount but in our branch at least the latency is lower.

Note that @dave96 has suggested some fixes for correcting the errors in those latencies here: macOS Round Trip Latency

We’ll probably look into that again too when we spend more efforts on Pajam again in the future. Good luck!

[simonhill-fr]

Thanks a lot @yairadix, I’ve built the examples from your fork and the results are really great! The playback latency is drastically reduced!
Seems very odd that JUCE still struggles to get this right, seems like essential stuff to me but maybe most people are using it to build plugins…
Did you suggest a pull request to integrate these changes ?

[yairadix]

@simonhill-fr

Did you suggest a pull request to integrate these changes ?

No, I didn’t.
We have several changes from the main JUCE branch for various things, and indeed we try get those changes upstream because we want everyone to enjoy fixes (and test them too), and also it will reduce our merging burden.
Sometimes our contributions and fixes get upstream, but many haven’t yet (52 files changed, 1532 insertions(+), 145 deletions(-)).
What sometimes worked was sharing fixes in the forum, PRs haven’t been more fruitful than that, see: Pull Request policy thread - #41 by yairadix