faust icon indicating copy to clipboard operation
faust copied to clipboard

Faust VST/AU plugins - report latency to host?

Open matthewjumpsoffbuildings opened this issue 4 years ago • 10 comments

I'm very new to Faust, just testing it out currently. One thing I have noticed is if I use the faust2au or faust2vst commands to generate plugins (an amazing feature btw) - there doesn't appear to be a way to report the introduced latency to the host/DAW?

For example, if I am using a lookahead compressor/limiter which introduces n samples delay to the signal, based on the lookahead seconds and the sample rate. There doesn't appear to be a way to get the generated VST/AU plugin to report this to the host? Unless I am missing it in the docs.

I guess this can not be done automatically in the general case. How do VST plugin developers do that in general?

sletz avatar Jul 19 '21 03:07 sletz

I had a quick look - in case of the VST3 SDK this seems to do it

https://steinbergmedia.github.io/vst3_doc/vstinterfaces/classSteinberg_1_1Vst_1_1IAudioProcessor.html#af8884671ccefe68e0a86e72413a0fcf8

In the case of AU, kAudioUnitProperty_Latency seems to do it

https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/TheAudioUnit/TheAudioUnit.html#//apple_ref/doc/uid/TP40003278-CH12-SW20

So given that there isnt a solution for this already, perhaps would make sense to have some kind of native function reported_latency(int samples) or something like that, that the compiler could then generate the relevant platform specific code? This would work differently for different targets, eg faust2au, faust2vst, faust2juce etc?

Thanks for investigating. My point is that if the compiler cannot know the latency automatically, there is no point in adding a new function AFAICS. We may better have a new option like -latency <num> in some faust2xx tools to setup the underlying getLatencySamples or kAudioUnitProperty_Latency code depending of the used model.

sletz avatar Jul 19 '21 06:07 sletz

Oh the compiler flag option would certainly be the simplest option for plugins that introduce a fixed amount of latency.

However, the reason I suggested using a function is that AU/VST etc support plugins changing their reported latency in response to settings changes, so I would say that you might want to do something like:

d = vslider("Delay",0,0,256,1);
process = de.delay(d,d) : attach(_, reported_latency(d));

I want to chime in that I've thought about Faust needing a "reported_latency" function too, approximately the same way @matthewjumpsoffbuildings described above. In Radium I'm using Faust for various filters and other things, and I've gotten the impression from users that it's somewhat of a problem for certain types of music when latency is not compensated.

kmatheussen avatar Jul 27 '21 10:07 kmatheussen

We could possibly prototype this using the ffunction primitive way in a very "hackish" way, like in the following code:

import("stdfaust.lib");

reported_latency = ffunction(float reported_latency(float), "latency.h", "");
d = vslider("Delay",0,0,256,1);
process = de.delay(d,d) : attach(_, reported_latency(d));

Then having the architecture file implement the C reported_latency function.

sletz avatar Jul 27 '21 10:07 sletz

Is there any news on this?

I'd very much appreciate if this could move forward. Even if it's "just" the compiler flag that would be great.

magnetophon avatar Jul 07 '22 17:07 magnetophon

+1 for the 'in-dsp' solution reported_latency(int samples)

I think I saw some plugins even change the reported latency dynamically, depending on settings (e.g. look-ahead in compressors).

trummerschlunk avatar Jul 07 '22 17:07 trummerschlunk

Nothing new.

sletz avatar Jul 07 '22 17:07 sletz