ARA and juce::BufferingAudioReader

I encounter audio issues using the juce::BufferingAudioReader in the ARAPlaybackRenderer. Sometimes, the read() method returns false (mostly when starting playback or when looping). The problem occurs with the ARAPluginDemo (JUCE 7.0.2). FYI, I just tested it with Reaper v6.67 on macOS 12.6 but it also happens with older macOS versions. This can be really annoying. Is juce::BufferingAudioReader really suitable for this real-time context? Perhaps, in real-time, the juce::BufferingAudioReader should be bypassed, but I’m afraid that it could introduce other issues. What is your opinion about it?

That’s a good point you brought up. The way in which BufferingAudioReader is used in the ARAPluginDemo is probably not appropriate.

The problem is, that in the demo we use a read timeout of 0 if AudioProcessor::isRealtime() returns true. Which would be the right thing to do in non-ARA mode. Because of this, whenever the DAW seeks or wraps around in the project, the buffer will probably not contain the requested samples and the BufferingAudioReader will return false immediately and start fetching the requested samples on a background thread.

However, when used in ARA mode, processBlock() is probably not called on a realtime thread even if the VST/AU wrapper has the realtime flag set. An explanation of this can be found in the ARA Library documentation under “ARA Design Overview → Host Signal Flow And Threading”.

So while it may be prudent to buffer reads to the host sample data, you can actually wait a bit to get the necessary data, but I’m hazy about how much. On average you have to obviously wait considerably less than the audio callback interval, but short waits when seeking may be all right.

For the ARAPluginDemo this would mean, that instead of 0 we should pass a small but sufficiently large value to setReadTimeout() even when the realtime flag is set.

3 Likes

Thank you for the explanation. I’ll try to adapt the read time out following the block size and the sample rate.