Studio One nonRealTime render hangs on Windows

I see you’ve changed this again… perhaps the fix is to revert back to the original and try and get Presonus to not block the message thread… They actually have the same issue in nonRealtime and Realtime when displaying a render progress bar.


Urgh. Is this hanging again in its current state? I thought Studio One was calling prepareToPlay on the message thread.

No, we’re back to making it basically always synchronous (as discussed above).

This fix ended up working for the non-RealTime render in Studio One… but didn’t fix the Real-Time render (they use the same progress display for both)… Given that, I’ll follow up with my contact at Presonus and see if they can fix the issue.



This remains problematic in the new Ableton.

10.1 will not always call prepareToPlay from the message thread in an offline render.

This causes offlineRender to build the graph async and causes dry audio at the start of the render process.

Removing the check to the message thread will make the prepareToPlay hang as it tries to obtain the MML.

Removing both appears to solve the issue, but I’m unsure why the MML is there in the first place, as it appears the only way into this function is from the message thread in the first place.

I’ve been having many issues with the AudioGraphProcessor.
I haven’t done thorough investigation, but the main issues seems to be around the async nature of the AudioProcessorGraph.
I’ve been experiencing:

  • Late buffer channels update after new buses layout being set
  • (Very) Late calls of prepare to play
  • Non-realtime hangs (especially Reaper and Studio One on Windows)

Unfortunately we don’t have enough time to work on a sync switch for the audio graph.
But it would be very welcome :slight_smile:

1 Like

We’re running into this and it’s biting us hard.

@Rail_Jon_Rogut Did you follow up with Presonus and find anything that can help?

1 Like

My current approach is to have a separate CriticalSection in the AudioProcessorGraph for building the rendering sequence, and to lock that section in buildRenderingSequence() and in processBlockForBuffer(…), while removing the graph.getCallbackLock() from those two methods. I have tested this with all hosts I could get my hands on, no issues so far.