Persistent crackling/ distortion with 'Cumulonimrod' preset of Plini plugin

Here’s the clip: Share, Embed & Upload Audio with Clyp

By default, the tone quality in the plugin interface is set to high. If I switch it to low, the crackling/ distortion reduces, but doesn’t go away ((the clip is recorded with this setting). I noticed this happens only for some presets, across all Neural DSP plugins. I wonder how can this be fixed.

Summary of my setup:

Audient iD4 with it’s own ASIO drivers.
Lenovo Thinkpad T590 (workstation) with i7 8th generation processor (4 cores, 8 threads).
24GB RAM and an NVMe SSD.
ASIO - 256 or 512 samples with 44.1kHz
Windows 10

The DAW I use is Reaper. The issue is persistent when the suite is run in standalone mode or with the DAW.

Hi @raj. That’s caused by performance issues on your laptop. Check the optimization guide if you haven’t already. This article should also help since DPC latency problems are quite common on laptops.

Hi @Gonzalo, I ran the test using Latencymon. Here’s the full report:


Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:00:47 (h:mm:ss) on all processors.


Computer name: WIN-P9IVHLOHBVM
OS version: Windows 10, 10.0, version 1909, build: 18363 (x64)
Hardware: 20N4CTO1WW, LENOVO
CPU: GenuineIntel Intel® Core™ i7-8565U CPU @ 1.80GHz
Logical processors: 8
Processor groups: 1
RAM: 24323 MB total


Reported CPU speed: 1992 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.


The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 153.60
Average measured interrupt to process latency (µs): 4.895123

Highest measured interrupt to DPC latency (µs): 147.10
Average measured interrupt to DPC latency (µs): 1.445860


Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 115.189257
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Highest reported total ISR routine time (%): 0.020015
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in ISRs (%) 0.020365

ISR count (execution time <250 µs): 20500
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0


DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 4437.036647
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Highest reported total DPC routine time (%): 0.218970
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%) 0.268837

DPC count (execution time <250 µs): 146705
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 6
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 1
DPC count (execution time >=4000 µs): 1


Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: explorer.exe

Total number of hard pagefaults 57
Hard pagefault count of hardest hit process: 42
Number of processes hit: 6


CPU 0 Interrupt cycle time (s): 2.797447
CPU 0 ISR highest execution time (µs): 115.189257
CPU 0 ISR total execution time (s): 0.076450
CPU 0 ISR count: 20399
CPU 0 DPC highest execution time (µs): 4437.036647
CPU 0 DPC total execution time (s): 1.001375
CPU 0 DPC count: 145768

CPU 1 Interrupt cycle time (s): 2.897110
CPU 1 ISR highest execution time (µs): 22.325301
CPU 1 ISR total execution time (s): 0.000173
CPU 1 ISR count: 101
CPU 1 DPC highest execution time (µs): 169.680723
CPU 1 DPC total execution time (s): 0.005408
CPU 1 DPC count: 248

CPU 2 Interrupt cycle time (s): 1.365486
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 65.960341
CPU 2 DPC total execution time (s): 0.001264
CPU 2 DPC count: 161

CPU 3 Interrupt cycle time (s): 1.352966
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 72.386044
CPU 3 DPC total execution time (s): 0.000226
CPU 3 DPC count: 24

CPU 4 Interrupt cycle time (s): 0.862581
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 18.3750
CPU 4 DPC total execution time (s): 0.000318
CPU 4 DPC count: 59

CPU 5 Interrupt cycle time (s): 1.225214
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 47.730924
CPU 5 DPC total execution time (s): 0.000085
CPU 5 DPC count: 9

CPU 6 Interrupt cycle time (s): 2.358832
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 34.818273
CPU 6 DPC total execution time (s): 0.002287
CPU 6 DPC count: 367

CPU 7 Interrupt cycle time (s): 1.990758
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 63.466365
CPU 7 DPC total execution time (s): 0.000530
CPU 7 DPC count: 77

If you already went through the usual optimization tips and your laptop is connected to the power outlet, you should start by disabling devices from the device manager that could cause latency issues. The first one to try is usually the Wifi/Bluetooth driver.

Be sure to check the Drivers tab on LatencyMon as well. Most of the time these problems aren’t caused by just one driver. Once you find them, you can follow the procedure described in the article above or just google the problematic driver and add “latency” at the end (Ex: Wdf01000.sys latency).

I found a similar case which was fixed by disabling the Wifi driver:

Okay, i’ll check the link and report back. I noticed something weird. I have a desktop computer and a 16 inch Macbook with 16GB of RAM too. The problem is persistent all across these 3 devices I tested on. How is this possible? Could the audio interface be a problem? If so, then I still have a return window open until tomorrow. Let me know!

That’s unlikely, unless the audio interface is defective.

Got it.

I disabled the Wifi adapter, CPU throttling, disabled USB power saving mode and reduced the buffer size to 64 samples and ran latencymon again. Here’s the result:

Your system appears to be suitable for handling real-time audio and other tasks without dropouts.

Seems like the poor results as posted previously show-up only when the buffer size is set to 512 samples.

After that, I tried the plugin on standalone mode. The crackling level is still same. Please have a look at this new clip (recorded with Reaper):

Rest of the presets work fine (with occasional-random clicks), it’s a handful of presets like ‘Cumulonimrod’ and ‘Simon Grove - Plini High Gain Rhythm’ that cause crackle. And I really liked these.

Additional information:

I own 3 plugins - Plini, Nolly and Nameless.

Signal chain - Guitar, Audient iD4 interface, Standalone plugin (64/ 128/ 256 samples at 44.1) and finally routing the output to Audio Technica ATH-M50x.

Thanks for the clip. I think the glitches are greatly reduced if you compare this example with the previous one. I’m still not sure about the noises before each chord. Are those glitches as well?

Most of the distortion present in this example is just the plugin clipping. Dial back the input/output knobs until the grey indicators at the top of each meter disappear.

Please send a clean DI file to You can attach a processed example of the same file as well to make the comparison. We’ll try to replicate it with a similar setup.

I have the same issue, crackling and distorted sound (in all presets I might add). Doesnt matter if I use Archetype as a standalone plugin or as a VST loaded in Studio One. I dont hear any difference in high or normal sample mode either. I´ve run Latencymon and my computer is fit for fight, no problems there.

Focusrite Scarlett 2i2 interface, 2nd gen with updated drivers.
Intel i7 CPU, quadcore
32 gb ram
512 SSD system drive

What can I do? No other plugin I use causes problem on my system. I can easily load 3-4 different kontakt tracks, Omnisphere and other more demanding plugins without any issues. I really love the Archetype but with this crackling going on it´s unplayable and getting kind of frustrating.

Did you go through the steps mentioned in the optimization guide? Also, keep in mind that LatencyMon might show the “Your system appears to be suitable for handling real-time audio…” message, but at short buffer sizes, only very low execution times of DPCs and ISRs become acceptable. It’s a better idea to aim for <100 on all rows.