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