I’m asking this question here because my DAW is based on TracktionEngine.
I am developing a new limiter plugin, which works perfectly with Windows Audio drivers on multiple machines. But it has dropouts and discontinuities on machines with ASIO drivers (regardless of buffer size…and using my TracktionEngine based DAW on all machines).
I would think that a plugin is totally isolated from the drivers. But, since I am seeing dramatically different results, I am wondering if my DAW should be handling things differently when ASIO is used.
Are there differences that I should be aware of when TracktionEngine interfaces with ASIO? Maybe some additional setup or configuration changes?
Digging further, this is happening even with Pro Tools, again with ASIO driver.
So, it is definitely not a TracktionEngine issue.
What I need to find out is what is different with handling ASIO versus Windows Audio, for example, that might cause this?.. See symptoms in previous posting.
And, is there any special handling of ASIO that will mitigate this?
Have you tried with a number of devices and perhaps different ASIO drivers?
It sounds to me like the drivers are just not implemented very well so the callback timing isn’t consistent?
Yes, three different computers (Windows 10) and both Pro Tools and my DAW with both Windows Audio drivers and ASIO. And the ASIO drivers include ASIO4All and Dante Virtual Sound card.
The situation baffles me because I am not doing anything unusual in my processBlock. I have a 30ms look ahead buffer. But it is all inline code, implemented as a few loops. And any allocations are handled in prepareToPlay.
It is especially puzzling because I have a delay plugin with much longer delay buffers, and that all works perfectly with the ASIO drivers!?
I am re-implementing the look ahead buffer today with the juce::AbstractFIFO class. I will report back with how that goes.
No, I have not done that yet. But, the bizarre thing is that I can comment out all of the code except the 30ms delay, and the issue still occurs!? So, as mentioned, today I am re-implementing the delay using juce::AbstractFIFO on the possibility I am making some sort of mistake in my delay code. In hindsight, juce::AbstractFIFO is a better way to go anyway.
Refactoring my code to take advantage of juce::AbstractFifo has solved the issue for now. It strongly suggests I had something wonky in my indexing for the look ahead buffer.
It still does not explain why it worked with Windows Audio drivers!?? So that remains a mystery.
But this is a reminder to myself and hopefully for others to use the builtin juce methods when possible. Just as we should use the STL when possible. In both cases, the code has been vetted by many, many users, and so is more likely to be correct and handle edge cases. Lesson learned…again!
