InterprocessConnection connection attempts block render callback of DAW (dropouts)


#1

After upgrading from 3.1.1 to 4.1, InterprocessConnection connection attempts show 100% CPU spikes, probably inside connectToSocket(). Happens when a connection can not be made. 

The spikes are short, but hefty enough to cause drop-outs and hickups in several DAW that host a Juce plugin or Juce-based ReWire device (seen with Cubase and Ableton Live, while Studio One and Reaper are not affected. Obviously, each DAW shows a different vulnerability to CPU spikes). As a consequence, periodical connection attempts, e.g. inside a ReWire device, can render an entire PC useless for audio applications.

This has not been an issue with 3.1.1. It's an issue on Windows only.

I did not find the time to compare the socket code side by side yet. Will do so as soon as possible. Maybe the authors have an idea where to look first?


#2

Had a look at juce_Socket.cpp now, comparing Juce 3.1.1 and Juce 4.1. Unfortunately, there's no easy way for me to spot any obvious place in what looks like a major rewrite of the entire file to me.

I'm not that firm at debugging on Windows, especially setting breakpoints based on CPU load is still a mistery to me (if at all possible). Since single-stepping through the code won't show the CPU load (obviously), how would you go about finding the culprit?

 


#3

Now that I reverted juce_Socket.cpp, .h (and only these files) to a previous release known to work (3.1), the spikes still occur. Only on Windows. Apparently this issue was not introduced with 4.1 and is possibly not related to the socket implementation directly.

Still, the problem disappears, if I comment out the call to connectToSocket() ... 

Please don't scratch your heads yet. I'll report back, if this has anything to do with sockets at all. If not I'll remove this thread. I'm sorry for the noise.


#4

Thanks - keep us posted if you find any clues!


#5

Found it!

Nothing is wrong with Juce sockets. It was all my own fault. 

The render callback inside my Juce-based ReWire device (or is it called engine?) was checking if the IPC was connected. This clashed with the connection attempts carried out periodically on another thread, forcing a short wait on the render thread. This happend to block some DAWs, long enough to cause hickups and dropouts. This happening after an upgrade to Juce 4.1 was pure coincidence.

In order to get rid of the in-depth check with isConnected(),  I added an Atomic status flag to my own class which is set and unset by connectionMade() and connectionLost() respectively. This eliminated the load on the render callback and solved the problem.

Two lessons learnt:

1) ReWire devices are running even if the user did not add them to the DAW project. Every DAW behaves different in this regard.

2) Checking an IPC with isConnected() is costly enough to not do it on a render thread.

I'll change the subject line to reflect this. Hopefully others will find it helpful. Thanks for listening.