ActionBroadcaster 64 bit windows issue


There is a problem with the ActionBroadcaster when it is used in a 64 bit application on Windows to send messages from one thread to another.
The same code used in 32 bit applcations on Windows or 32 and 64 bit applications on Mac is fine. However a 64 bit application on Windows produces deadlock like situations

In the last months I’ve developed three completely different audio plugins and each of them ended up to freeze the system for I while when I loaded the 64 bit VST or 64 bit AAX plugin on Windows, no matter which host was used.
The same plugin code runs fine as 32 bit AAX or VST on Windows and 32 bit and 64 bit AU/VST/AAX on Mac. The only thing the plugins had in common was that there where messages sent from the processor thread to the gui thread using an ActionBroadcaster / Actionlistener.

Finally I made a simple test plugin that uses the totally basic code created by the Introjucer. The only thing I’ve added is to make the AudioProcessor an ActionBroadcaster and the Editor an ActionListener.
Each time the processBlock is entered I send one ActionMessage and the GUI acts as an ActionListener and repaints a coloured rectangle when it receives a message. Nothing else was added.
This simple testcase shows the same behaviour:
Everything works fine except 64 bit VST and 64 bit AAX plugins when they are loaded into a 64 bit host. After the playback is running for a random while the computer freezes. Sometimes for seconds and sometimes for minutes.
The more I move the plugin window or I switch the focus from the PluginEditor window to the host and back, the more often the freezes appear. Sometimes it freezes immidiately and sometimes it takes a minute or two.
As soon as the call to sendActionMessage() is removed, the freezes are gone.

Are there any issues with thread safety of the ActionBroadcaster? Or is this class simply not designed for what I’m trying to achieve? If so, why does it work on all platforms except for 64 bit Windows?

I’ve attached the slightliy modified TestPlugin code produced by the Introjucer.
Unfortunately I couldn’t attach the compiled 64 bit Windows VST plugin DLL as well, because of the upload size restriction of 512 kB.
If you don’t want to compile it yourself I could send you the binary via email.

Jules, it would be nice if you could have a look at this.


You can download the compiled DLL here:


Do you have stacktraces while the freezes appear?


You should be very sceptical before blaming the Actionbroadcaster class… That class just uses the same Message posting mechanism as all the other messaging classes, so if it failed, then so would Timers, AsyncUpdaters, ChangeBroadcasters, etc etc. Pretty much nothing at all would work!


Yes I know and that’s what I am. But I reduced the test case to nothing but the ActionBroadcaster (I even removed every code in the actionListenerCallback, so it does nothing at all) and the random freezes are still there.

This is the processBlock of the Processor:

[code]void TestPluginAudioProcessor::processBlock (AudioSampleBuffer& buffer, MidiBuffer& midiMessages)
sendActionMessage(String::empty); //comment this out and the freezes on 64 bit Windows are gone!

for (int i = getNumInputChannels(); i < getNumOutputChannels(); ++i)
    buffer.clear (i, 0, buffer.getNumSamples());


And this is the the actionListenerCallback:

void TestPluginAudioProcessorEditor::actionListenerCallback(const String &message) { }

The rest of the code is the empty plugin code of the TestPlugin created by the Introjucer except that obviously the Processor is made an ActionBroadcaster and the Editor is made an ActionListener.
What else could be the problem if there isn’t something special with the ActionBroadcaster on 64 bit Windows plugins?
I’m willing to do as much tests as necessary before bothering you but I have no idea how to narrow things down to the real problem more than I’ve already done. Any ideas what to do?
NOTE: the freezes only appear during playback and when the plugin window is moved or is getting the focus.

Unfortunately no because during the freezes the whole system freezes and even the Profiling tools of Visual Studio do not work correctly. As the apps (for example Pro Tools Dev 11 or Sonar 64 bit) do not crash but just freeze for a while, there is no crash report.


Oh well sending a message inside processBlock is a big no-no! It involves an OS call, which may block for an unspecified amount of time, and time-sensitive hosts won’t like that. Most likely you were just lucky to get away with it on 32-bit windows rather than this being a 64-bit issue.


Ah, thanks a lot for the info!
I was afraid of getting exactly that answer but nevertheless it’s really helpful info.

So what is is the safest way to handle information from the processBlock over to the GUI (if for several reasons setParameterNotifyingHost cannot be used)?
Again sorry for bothering, but I was missing this important info and there is nothing mentioned in the docs anywhere.


This topic may help: What’s best practice for GUI change notification?


is the forum broken? Where is vinnie praising his vflib? :wink:

simplest: just use a Timer in the GUI and check a flag which is set in the processBlock.
You can also use a CriticalSection, if you only hold it for a short time, and don’t make any allocation in it, to have integrity when accessing process data.
If you don’t like a lock you can also use a simple LockFree-Fifo (i posted something for a while in forum)


Thanks a lot for your suggestions. I’ll check it out.