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

[Kjetil S. Matheussen]

On 23 Oct 2002, Benno Senoner wrote:

> 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
>

Interesting. But one idea I just got...

Could it be possible to overcome all problems mentioned just by simply
adding jack-support to the wine-server? Then someone could make a simple
windows-program for chaining directx and vst plug-ins.

I dont know how the wine-server works though, so please shout out if its
not possible.


> 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
>
>
>
>
>