[gst-devel] VST Audio Plug in approach using Gstreamer and Linux OS with ARM Cortex A8 processors

[Paul Davis]

On Sat, 2009-01-10 at 10:10 -0800, thx1138 wrote:
>  
> So, If I understand your response, VST plugins compiled for Windowx/MacOSX

they are compiled for an OS *and* a CPU architecture: windows/x86 and
OSX/ppc or OSX/x86. you cannot take these plugins an expect to run them
on linux/arm. you could not even run them on windows/arm or
windows/alpha (for example).

> would need to be recompiled to run as plug-ins using Gstreamer.

if you use an ARM processor, they would have to be recompiled one way or
another even if you ran windows and use VST.

> Wine just give a Windows emulation for x86 emulation I gather.

not precisely, but close enough. the point is that the plugins will not
run on a different CPU architecture without being recompiled. unless you
have source code for the plugin, its a non-starter.

> Our software manager has decided to build our Dolby, DTS, etc. plug-ins to
> use Gstreamer as interface which I believe is fine, I just need other VST
> applications to be ported to Gstreamer.

from the sound of it you need VST *plugins* not VST-supporting host
applications.

> I wish I had some quick way to evaluate Gstreamer plug-ins versus VST
> approach. Perhaps this will take some effort to gather benchmarks on
> latency.

the VST architecture has no impact on latency. the audio latency is
determined by the host application, the plugins have no way to affect
it.

i do not know enough about gstreamer to understand its approach to
latency, but i do know that at least as of a few months ago, gstreamer
was not designed around the same principles as most low latency audio
APIs (ASIO, CoreAudio, JACK). however, it may still be able to get down
to the range you need - unless you are creating an application for
pro-audio and/or musical performance, the acceptable range is pretty
wide.