Florent,
I've recently been discussing this with another developer via email, so I hope you don't mind if I take the liberty of quoting here much of what I said in that discussion as I think it is applicable to your question. The short answer is "it's possible, but with significant limitations that need to be understood".
The first point is that it's important to distinguish between different uses of "real-time", namely strictly real-time versus a looser sense of "causal(*), and fast enough to produce results as quickly as it gets input".
Strictly real-time means that the plugin is able to guarantee to meet a known response deadline -- meaning for example that it is predictable enough to be used when serving short audio buffers directly to a hardware soundcard. This is a much stronger meaning of the term than "causal and fast enough"; in particular it refers to code that is not only suitably bounded in algorithmic complexity but also avoids taking any mutex locks, making any system calls, or allocating any memory on the heap.
The major limitation with using Vamp plugins in a real-time context (in the strong sense) is that the Vamp SDK uses C++ standard library classes, such as string and vector, to pass data back from the plugin's process function. These classes routinely use heap allocation for dynamic storage of data, and so are not generally
suitable for use in a real-time context. It's possible to write plugins using the SDK that satisfy the "causal and fast enough" test, but not the "strictly real-time" test.
As an example of the distinction, consider e.g. a "real-time" spectral visualiser (for which "causal and fast enough" is almost certainly good enough, the graphical part of the visualiser program is unlikely to be able to support any stronger guarantee anyway, and the existing Vamp SDK should be fine) vs. an analysis component in a real-time audio processing effects unit (for which "strictly real-time" is required).
This limitation isn't built in to the Vamp API itself (that is, the C API defined in vamp/vamp.h -- which is the only interface that is relevant to binary compatibility), it's simply a result of decisions taken for plugin authors' convenience in the current SDK. It would not be hard to define an alternative C++ plugin base class that used
preallocation, avoided standard library classes, carried out no heap allocation in process(), and was therefore real-time safe, but it would obviously require that the plugin was written appropriately (with features of a known size, etc). If you'd very much like to see such a thing, let me know, because it's a real possibility.
Of course, one could also write plugins directly using the C API in vamp/vamp.h instead of using the SDK classes at all. There would be no problem making such plugins real-time safe.
The same logic applies to the host side of things -- although it wouldn't be hard to write a host using vamp/vamp.h directly, and a host written specifically for a real-time context would probably find that a reasonable thing to do.
Finally, there is no way for a plugin to indicate to the host whether it is causal and/or real-time safe, which means that a real-time host would need to know in advance which plugins were appropriate. Again, this is an addition that is quite likely to appear at some point.
Chris
(*) - "Causal" refers to an algorithm that calculates results for a particular frame of input audio as it receives that frame, without significant buffering or lookahead. In the Vamp plugin context this generally refers to plugins that return individual result features directly from individual process() calls, rather than returning them all in a big batch from getRemainingFeatures().
