Hello,
I'm working on an application "audacity" which use the multi-os wxWindows lib. This application uses a feature available only on windows and Mac - the audio effects for the VST plug-ins.
Now I have done a winelib app to bridge the native dll (audio VST effects) with the native unix app.
It seems to be ok, all plugins are loaded. But, I would like to know if I must establish a link between wine and my linux app for some resources like the threads?
Thanks Olivier
What you could do is use SHM segments between the winelib app and Audacity. Otherwise, normal IPC will do - they are essentially two different programs, so you have to figure out how to route the audio between them. Sharing the bufferpool memory and swapping addresses via RPC would seem to be the best way forward - one RPC mechanism you might want to use is DBUS (see freedesktop.org).
On Sat, 2003-07-12 at 03:26, Evalet Olivier wrote:
Hello,
I'm working on an application "audacity" which use the multi-os wxWindows lib. This application uses a feature available only on windows and Mac - the audio effects for the VST plug-ins.
Now I have done a winelib app to bridge the native dll (audio VST effects) with the native unix app.
It seems to be ok, all plugins are loaded. But, I would like to know if I must establish a link between wine and my linux app for some resources like the threads?
Thanks Olivier
Thank you Mike,
Sharing the bufferpool memory and swapping addresses via RPC would seem to be the best way forward - one RPC mechanism you might want to use is DBUS (see freedesktop.org).
If I use this, do I must run Wineapp and audacity in a separate processes? And what do you think about the speed performance in the case of audio effects? Can it work in real time?
But, I thought that it was a problem of synchronization between the wine thread scheduler and the audacity pthread creation? In this case, is it possible to add a function in wine to attach linux thread in wine scheduler, I guess I'm wrong:)
Regards, Olivier
If I use this, do I must run Wineapp and audacity in a separate processes?
At the moment, yes, that is the case. Allowing normal Linux apps to dlopen() Wine and use it that way has been discussed before, but generally Alexandre seems to think it'd require a lot of work. I'm not entirely sure exactly what needs to be done.
And what do you think about the speed performance in the case of audio effects? Can it work in real time?
Message passing via UNIX domain sockets is extremely fast. If there was no buffer copying overhead, I think you could get close to native performance. Basically it'd go like:
1) Audacity sticks a buffer into the SHM area ready for processing 2) Audacity sends a message to the plugin process, and goes to sleep waiting for a response. 3) Plugin process wakes up, reads the address of the buffer from the socket, and performs the processing on it. 4) Plugin sends an ACK reply back to Audacity and goes to sleep waiting for the next message.
I'd guess that's roughly how it'd work, but I know very little about audio apps.
But, I thought that it was a problem of synchronization between the wine thread scheduler and the audacity pthread creation?
Wine threads are mapped to Linux threads, so Wine doesn't have a scheduler of its own (except for 16 bit apps). I think it's more a problem of ensuring Wine knows about any threads that are going to interact with it.
In this case, is it possible to add a function in wine to attach linux thread in wine scheduler, I guess I'm wrong:)
I'm not sure, but basically if you create a thread using Wine, then that thread can call the Win32 APIs. If you don't, it can't.
I believe there are other problems with the process environment, but Alexandre would have to explain that.
thanks -mike
-
Evalet Olivier -
Mike Hearn