Seems that, the UI thread interferes with the communication thread.
when I open a menu, there would be a little delay in tcpip thread, then a burst after the delay.
tcpip thread?.. Whose thread is that?
I am having a similar issue here.
I made a VST plug in based on the sample. It communicates with another process using the InterprocessConnection class. It seems to work fine in some hosts (like JUCE sample host and AudioMulch) but not in others (like Cubase). Whenever I move a slider in Cubase, everything else (SendMessage) stops and waits for UI of Cubase to be done.
Ok sorry for the delay, I had to do some more testing to confirm the issue that I am having with both of my Audio Unit and PC/MAC VST plug-ins.
I am working on a cross platform plug-in that communicates with a Juce based application over TCP/IP. The communication is done via InterprocessConnection class; messages are received and sent in the plug-in’s processBlock method. When the plug-in is connected to the “Server” (Juce based application) everything works great up until I touch (Click/Mouse Down) any of the host’s control(s) e.g. Master Channel Volume Faders, jog wheel or scrub control, buttons etc… In Cubase4 and Logic all audio stops and or stutters until I release the control or UI widget that I’m moving. I don’t get glitches when I use controls on the plug-in itself.
Why would playing with the host’s GUI disrupt audio when my plug-in is instantiated and connected?
What do you think is happening here? Could the InterprocessConnection’s thread be conflicting with the host audio thread in anyway?
The plug-in is an instrument/synth.
It sounds like either your UI is holding onto a critical section that’s also used by the audio thread, or that you’ve got a communication thread whose priority is higher than the audio thread, and that’s causing conflicts.
Just for forum documentation purposes.
We figured out the issue. Very simple actually…
The problem was here.
InterprocessConnection::InterprocessConnection ( const bool callbacksOnMessageThread = true, const uint32 magicMessageHeaderNumber = 0xf2b49e2c )
callbacksOnMessageThread if true, callbacks to the connectionMade(), connectionLost() and messageReceived() methods will always be made using the message thread; if false, these will be called immediately on the connection’s own thread.
Thanks Jules.