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