ARA Plugin Demo Timeout

1

we’re trying to have real time audio playback from the ARA Plugin Demo, and currently we’re running into an issue with this line of code from the demo:
JUCE/ARAPluginDemo.h at 69795dc8e589a9eb5df251b6dd994859bf7b3fab · juce-framework/JUCE · GitHub
here, reader is a PossiblyBufferedReader, which resolves to a JUCE BufferingAudioReader (JUCE: BufferingAudioReader Class Reference). In the BufferingAudioReader’s read function, we keep hitting a timeout error (see this line: https://github.com/juce-framework/JUCE/blob/bbd6ccbc863edec3150e1e024e4fa3f6368025[…]s/juce_audio_formats/format/juce_BufferingAudioFormatReader.cpp).

initially playing audio the reader doesn’t fail, but audio still doesn’t come out. and if i pause the playhead and restart it it will fail/timeout for the first ~1.5 seconds of reading audio.

would this be causing issues related to hearing playback while using the ARA plugin?

we’ve also checked that the audio and reaper have the same sample rate, and that the plugin and the audio have matching numbers of channels

lastly, here’s the details of my computer and software:
MacOS: 13.0 (22A380) M1
Reaper: v6.75
ARA_SDK: releases/2.2.0
CMake: 3.25.2
JUCE commit: 9f6432544

thank you :]

1 Like
2

running into this same issue!

1 Like
3

update, i got the playback working that was related to some code i had written in the EditorRenderer. but there is still some timing out that prevents playback for about 1.5 seconds

4

I’m afraid there is no easy solution for this problem. The BufferingAudioReader can only ensure that no blocking call will be made on the audio thread, however it cannot guarantee that the samples will be available immediately after seeking to a different playhead position.

The failure in this case means that the requested samples aren’t readily available in the buffer, and the BufferingAudioReader needs time to fetch them on a background thread. Until the samples become available only silence can be “played”.

Handling these situations fall to the plugin developers, as the correct solution could be application specific.

The ARA plugin demo could have such an application specific solution itself that does even more caching, but the demo already contains a lot of code, so this aspect was handled by the readily available and general purpose BufferingAudioReader. This however has the limitation that you’ve observed.

1 Like
5

There’s a funny thing about ARA playback.

Before ARA, effect plugins would just get samples they need to process and didn’t need to explicitly request them. Whether the DAW used some form of buffering before us was no concern for us. With ARA however, we need the step of asking the DAW to give us the samples that we’re applying the effect on.

Ideally we wouldn’t need to buffer anything, we’d just ask for the samples and block until the host gives them to us. Then there would be no timeouts or blank samples at start of playback. Unfortunately there exists an important host where this doesn’t work so well and hence the buffering mechanism exists as a workaround for it.

1 Like
6

Sadly, ARA just as any API, being implemented differently between hosts.

Some key points worth to consider:

  • Try to contact the host developers. If there’s something the hosts isn’t doing correctly, it would be beneficial for any party if the host improve or fix their implementation.

  • Workarounds/mitigations. For example in the case above, you’d might like to not buffer for some hosts, or maybe apply different caching approach for one host rather than another.
    Also, you can try fiddling with the setTimeout value where anything below 0 considered indefinite iirc.

2 Likes