@ the developers:
It looks like Tracktion/Waveform is the only daw that blocks the audio thread when the user thread (Vst2->effEditIdle in dispatcher) needs more than 100% CPU-time. This looks weird to me.
You can try it for yourself : make a dummy VST2 with a delay in effEditIdle and hear the results in the audio thread.
What are your opinions?
User vs Audio Thread
-
- KVRist
- 377 posts since 16 Apr, 2004 from Antwerp
-
- KVRAF
- 1790 posts since 30 Dec, 2012
Hmm, I don't think so...
We use the JUCE plugin hosting and the Vst2::effEditIdle dispatch happens on the message thread.
Do you perhaps have a lock in your dispatcher? That will be called concurrently with Vst2::effProcessEvents and Vst2::effEditIdle.
We use the JUCE plugin hosting and the Vst2::effEditIdle dispatch happens on the message thread.
Do you perhaps have a lock in your dispatcher? That will be called concurrently with Vst2::effProcessEvents and Vst2::effEditIdle.
-
- KVRist
- Topic Starter
- 377 posts since 16 Apr, 2004 from Antwerp
That's indeed the correct way. Hmm...We use the JUCE plugin hosting and the Vst2::effEditIdle dispatch happens on the message thread.
If you mean by lock a synchronisation object like mutexes/semaphores, then no.Do you perhaps have a lock in your dispatcher?
Did you try with a dummy VST2 that blocks the EffEditIdle with p.e. a sleep() win api call?
Do you agree that such a thing shouldn't interfere with the audio thread?
-
- KVRAF
- 1790 posts since 30 Dec, 2012
I tired building one of the examples from the VST SDK but it's a hot mess and the project file won't open in Xcode.
I usually build plugins in JUCE and they don't use the EffEditIdle callback, they directly run their own timers on the main message loop.
So I went brute force from the hosting side and put a "sleep (10ms)" in the places we dispatch the "Vst2::effEditIdle" callback (which is where the call would come through to the plugin) and this didn't make any difference, no dropouts, nothing.
I think if you'll need to provide some stack traces which show the effEditIdle callback halting the process callback. Our plugin hosting is also completely open source, you can try building the PluginDemo and see exactly what's happening from the hosting side: https://github.com/Tracktion/tracktion_ ... uginDemo.h
I usually build plugins in JUCE and they don't use the EffEditIdle callback, they directly run their own timers on the main message loop.
So I went brute force from the hosting side and put a "sleep (10ms)" in the places we dispatch the "Vst2::effEditIdle" callback (which is where the call would come through to the plugin) and this didn't make any difference, no dropouts, nothing.
I think if you'll need to provide some stack traces which show the effEditIdle callback halting the process callback. Our plugin hosting is also completely open source, you can try building the PluginDemo and see exactly what's happening from the hosting side: https://github.com/Tracktion/tracktion_ ... uginDemo.h
-
- KVRist
- Topic Starter
- 377 posts since 16 Apr, 2004 from Antwerp
Ok, thanks dRowAudio for your efforts, I'll investigate further.