Hey,
A few weeks ago, I tried AlphaSound’s defeedback. It doesn’t work.
AlphaSound told me that the Fourier system’s latency was to blame…
Will HyperPort allow me to use this plug-in?
It is not a hardware issue. From what I understand, the problem lies within the DFB plugin itself and is currently being addressed.
I honestly do not understand why, whenever DFB fails to run properly, people immediately blame the hardware. While it is true that DFB uses an algorithm that requires significant CPU processing, extensive testing clearly shows that the plugin does not utilize CPU resources efficiently and that the implementation of the algorithm itself is heavy. Anyone with a basic understanding of VST3 systems can verify this with minimal testing.
The fundamental issue is that the processing latency required by DFB is effectively fixed, whether on Windows or macOS. In other words, the minimum RTL required to guarantee stable operation appears to be consistent across platforms based on the collected test results.
Let me explain using recent tests with Waves Live Box MADI as an example.
Below a buffer size of 32, the plugin could not run at all.
At 64 buffer (RTL 2.2 ms), only 1 instance was usable.
At 128 buffer (RTL 3.5 ms), 5 to 6 instances were usable.
At 256 buffer (RTL 6.19 ms), up to 12 instances were usable.
At 512 buffer (RTL 11.52ms), up to 15~16 instance were usable.
and This is Live Box Dante result,
At 32 Buffer to 128 Buffer (RTL 1.84 to 3.76ms), 0 instance was usable.
At 192 Buffer (RTL 5.09ms), 2 instance was usable.
At 256 Buffer (RTL 6.43ms), 6 instance was usable.
At 512 Buffer (RTL 11.76ms), 6 ~ 8 Instance was suable.
Now comparing this with macOS testing:
On macOS (M3 Ultra + DAD system with Waves Live Performer):
At 96 buffer (RTL 2.32 ms), only 1 to 2 instances were possible.
At 192 buffer (RTL 4.32 ms), 5 to 6 instances were usable.
At 256 buffer (RTL 5.66 ms), the number of usable instances increased sharply to around 10.
At 512 buffer (RTL 10.99 ms), approximately 20 instances could run.
When overall computer performance was comparable, similar RTL values resulted in roughly the same number of usable DFB instances. The number of usable instances was significantly lower when using a Dante I/O–based system, whereas a MADI I/O–based system allowed for a relatively much higher number of usable instances.
It is likely that increasing the buffer to 512 in a Fourier system and significantly raising total system latency would allow more instances to run. However, since Fourier is Dante based, applying the Dante system test results shows that below 5 ms RTL, not even a single instance can run reliably.
Using Waves Live Box or any Dante based I/O configuration with DFB, operation below 5 ms RTL was not possible. This result was consistent across all Dante based systems tested. At around 5 ms RTL, only one instance was reliably usable.
Ultimately, the system requires a higher total round trip latency so that the audio can pass through I/O, be processed, and return stably. Without sufficient overall system latency headroom, the plugin simply cannot operate reliably in its current form. If you set the Fourier server to the maximum available buffer size and also increase the Dante latency, you will likely be able to confirm that DFB runs.
1 Like
DFB has become popular almost like a trend and is being treated as some kind of benchmark for system performance. However, the reduction in dynamic range and the tonal loss introduced by the plugin are quite significant.
In addition, the core issue is still the plugin’s optimization. It makes no sense to shift the blame to system hardware when the same system can run many other VST3 plugins stably without issue. From my perspective, having worked for decades as an audio engineer and having directly witnessed and used countless generations of hardware and plugin systems as they evolved, the current situation is almost laughable. It is difficult not to react when the responsibility is misplaced like this.
Based on thorough testing of DFB’s audio impact and careful evaluation of the results, I would not recommend DFB if you are sensitive to vocal tone. The tonal degradation and dynamic range reduction are substantial.
2 Likes
Thank you for your reply.
Please note that I am not blaming the Transform Engine in any way.
I am a big fan and user of this device.
The reply I received blamed latency. The system latency is primarily due to Dante, not the Transform Engine.
I already understood that this plug-in requires a lot of resources and seems complex…
Have a good evening.
1 Like
No, not at all. If my comment was uncomfortable or unpleasant to read, I apologize. I am currently preparing a detailed response and will repost it shortly.
1 Like
Specifically, I am not sure what kind of latency the DFB developer is referring to as the issue. However, a live VST3 system should be designed first and foremost to run as many plugins as possible, as stably as possible, at the lowest possible latency. If someone is saying that the system should be adjusted to fit DFB, that would be sophistry. I doubt they actually meant it that way. I assume they were referring to the minimum latency required for the plugin to operate properly.
As far as I understand, the March update will introduce additional buffer size options in the software. If that happens, we will likely have more flexibility in allocating time between plugin processing and I O, which should provide more system headroom.
As for Dante latency, it is fixed.
The latency set in Dante Controller is fixed. You can select values from 0.25 ms to 1 ms or higher. Most devices default to 1 ms, and if you want lower latency you can set it down to 0.25 ms. This means the RTL introduced by Dante itself ranges from about 0.5 ms to 2 ms. Beyond that, additional RTL will come from the Dante card and the console. When you add the extra RTL generated by the rest of the system, you get the total RTL of the Fourier system.
At a 32 sample buffer, the RTL is 3.25 ms. At a 64 sample buffer, it is 4.25 ms. Currently those are the only practical low latency options, aside from 512 samples. I understand that future updates will introduce intermediate buffer sizes.
Based on my extensive testing, the data consistently shows that for stable use of a single DFB instance, the minimum required system latency exceeds 5 ms. It appears that the plugin needs at least that much internal latency to meet its audio processing deadlines without introducing noise. As RTL increases, it is of course natural that the number of usable plugin instances also increases.
There are technically far more complex plugins, such as IR based reverbs, and many of them are already very well optimized in terms of CPU usage and required processing latency. I understand that DFB is AI based, but is it the only AI based plugin? Of course not. There are many.
The real issue is that they do not acknowledge any potential shortcomings of the DFB plugin itself and instead continue to shift all responsibility onto the system. The same pattern appears in their Facebook group. People point to system issues, but no one mentions possible plugin level problems, even though they exist. It is somewhat ironic to be discussing this here, but in any case.
If anyone has deeper technical insight into this matter, I would appreciate a more detailed technical explanation.
1 Like
I do not like the idea that being able to run this plugin becomes some kind of absolute benchmark for the entire system.
If it does not work, then we simply do not use it. From a user’s perspective, we still have other options, so there is really no reason for this kind of argument in the first place.
2 Likes
I completely agree with you. If one plug doesn’t work, we’ll use another one… There are plenty on the market.
The goal of a forum like this is to ask questions, isn’t it?
1 Like
Yes! That’s right. 