bridge winelib app and linux app

[Mike Hearn]

> 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