[linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins on Linux in real time

Benno Senoner sbenno at gardena.net
Wed Oct 23 08:02:01 UTC 2002


I contacted the author of the VQF plugin about opinions of running
windows plugins under Linux. He is not subscribed to LAD so he told me
 to forward this mail to the list.
cheers,
Benno

On Tue, 22 Oct 2002, Benno Senoner wrote:

> We are currently discussing about the possibility to run VST or
DirectX audio
> plugins on Linux in real time.
> I remember you wrote an xmms plugin that allowed to run the windows
VQF plugin
> under Linux using wine & co.
> <snip>
> It would be cool if you could write on the linux-audio-dev list about
> experiences in that field.

I am afraid I will have to keep this short as I'm really busy at the
moment. I also am a long way from being an audio expert or wine so I
doubt
my experiences will be of much use to you hence I didn't subscribe to
the
list . Feel free to forward this to the audio-dev list and cc me on it
if
you wish

First, the solution I used for the VQF plugin was extremly clunky. There
was no way of letting the plugin run inside XMMS without causing
segfaults. They simply did not merge well no matter what I tried.

I suspect but never proved that it was how WINE has to lay out it's
memory
to be able to mimic how Windows sees things like segments. The layout is
drastically different to how a Linux app normally sees things. By the
time
a VQF plugin could be loaded, the two very differnet approaches to
managing memory simply did not work well together

In the end, the solution used was this;

1. At XMMS start, fork and exec an application that uses libwine to load
   the windows DLL. Communicate with the parent through pipes, sockets
or
   shared memory

2. Start up XMMS as normal

3. The plugin just implements stub functions for every routine a plugin
is
   meant to implement and communicates the information to the child

This had a number of issues. First, it was difficult to get information
from the plugin. It opened the sound device directly itself which meant
that visualisation data was not available.

At one point, this was resolved by hacking wine itself to write the PCM
data to a named pipe rather than playing to a device but needless to
say,
it was too ugly to live and couldn't really be distributed easily. (I
considered it unreasonable to get users to patch and compile WINE just
to
play a piece of music, visualisations weren't that important).

If I had a nice plugin, what I would try to do is set up two unamed
pipes
at application start to a child application using libwine. One pipe for
writing would send commands and one pipe for reading would take PCM
data.
I don't know how viable this is for you.

> I'm not a windows / wine expert but commonsense says me it should be
> possibile to run these windows plugins under Linux in real time with
small
> buffer sizes in order to get low response times (low latency).

I would be inclined to go the other way. With the above solution, I
would
try and buffer as much data as humanly possible to try and avoid the
overhead of calling wine constantly. For example, I would try and get 10
seconds worth of data from the windows plugin before starting to play
anything. Once I had the PCM data, it would not matter if the plugin
could
not make real time contraints.

> It should be possible to let wine handle the GUI stuff . (if word and
excel
> runs then it should be able to run plugin GUIs too).

It can, but remember that if you are trying to use this plugin with a
normal application, you are likely to run into a lot of trouble. At
least
I did, but this was a few years back. Things might be different now

I imagine you already have checked out how avifile loads it's plugins.
When I last looked at it (a few years back), it was using a stripped
down
version of WINE to just load the plugins and get the function pointers.
It
might be worth checking into.

-- 
Mel Gorman
MSc Student, University of Limerick
http://www.csn.ul.ie/~mel







More information about the Linux-audio-dev mailing list