Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins on Linux in real time
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
On Wed, 23 Oct 2002, Kjetil S. Matheussen wrote:
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.
Someone has done this, I believe: http://kt.zork.net/wine/wn20021011_139.html#2 Taybin -- http://www.piratesvsninjas.com
On Wed, 23 Oct 2002, Taybin Rutkin wrote:
On Wed, 23 Oct 2002, Kjetil S. Matheussen wrote:
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.
Someone has done this, I believe: http://kt.zork.net/wine/wn20021011_139.html#2
Wow, it allready exist. Hey, wine-people, this driver is really needed for real-time audio-work, and for programs as sound-editors, multitrackers and interactive dsp programs as pd, jmax, and a lot of others. Artsd (f.ex) is not an alternative in its current form, and probably never will be either. Its something else. I guess Paul or some other competant person can explain a bit more why jack is so important. --
> Wow, it allready exist. Hey, wine-people, this driver is really needed for > real-time audio-work, and for programs as sound-editors, multitrackers > and interactive dsp programs as pd, jmax, and a lot of others. Artsd > (f.ex) is not an alternative in its current form, and probably never will > be either. Its something else. I guess Paul or some other competant person > can explain a bit more why jack is so important. don't hold your breath for this one: - jack support is used for audio playback (to jack is seen just as an output device) - code is new, not reviewed, and not yet committed to wine - as of today it can only be used for sound output (not sound recording) (from a windows driver point of view) - port routing will not be easily solved. for example, it will be hard to match dynamic aspect of JACK port creation/deletion (unless we break away from windows API) - being able to run a VST plugin is one thing, providing all the relevant glue for all the streams might a bit more difficult - last, but not least, performance (and especially low latency) will be difficult to provide from a wine point of view (with today infrastructure) A+
On Wednesday 23 Oct 2002 19:52, Eric Pouech wrote:
- port routing will not be easily solved. for example, it will be hard to match dynamic aspect of JACK port creation/deletion (unless we break away from windows API) Just to jump on this one point :-)... How does Windows handle hot plugging of multiple USB audio/midi devices? Could not creation/deletion of jack ports do something similar (even if that meant, "unplug old jack device with n ports", "replug new jack device with n+/-m ports"... that's nasty...)
-- Peter
> Just to jump on this one point :-)... How does Windows handle hot plugging of > multiple USB audio/midi devices? Could not creation/deletion of jack ports > do something similar (even if that meant, "unplug old jack device with n > ports", "replug new jack device with n+/-m ports"... that's nasty...) that would be doable, but it'll require quite some work: - have some kind of watchdog thread to get the jack port creation/deletion (or maybe it exists thru callback) - implement device insertion/removal (at wine level) - allow hot plug of multimedia device which can turn in a several man.month project by itself A+
participants (4)
-
Eric Pouech -
Kjetil S. Matheussen -
Peter L Jones -
Taybin Rutkin