R5 library ladder filter (look at this crazy thing)

But Reaktor still clocks the data in at the sample rate and does all of it's processing between samples.

That doesn't make sense.

Reaktor knows how much buffer it needs to fill, and it uses all the available cpu to fill that buffer chunk as fast as it can go. In one part of the buffer, it might process 10 samples worth of 44100Hz audio in less than 1/44100 seconds… in another part, it might hit some slower code… maybe a blep or something, and take 2/44100 just to calculate a single sample of data…

That's why you get more buffer underruns with low latency settings… because there is less opportunity for 'lumpy' cpu requirements to average out.

Sounds right, That's true, once the data has already been stored there is no law that says the data has to be read by the serial clock and processed in sync with the serial clock. I picture the ensemble doing all of the necessary calculations before the next serial clock and stops. After it stops then there is time to do other chores. I always thought the sample rate was a timed interrupt that ran all necessary calculations. However it doesn't really have to have top priority. Something else can interrupt the ensembles calculations and hand control back to Reaktor when it's finished. It seems the daw itself should have top priority of all interrupts because it has to run all of the tracks. I think the soundcards asio buffer is filled by the daw but the soundcard itself is running its own timed interrupt that sends and receives the data stream at the audio sample rate. This way the sound card is on its own and never really gets interrupted by the computer hardware. So yeah, there is no reason a precompiled ensemble has to follow any rules at all. Let's see. ASIO Asynchronous means not synchronous, or free to accept data at any time into the buffer. So it's a simple Asynchronous input output buffer. Only the input and output and synchronized to a serial clock in reality. Which basically clearly shows why short asio buffers have overflows or "Lost Buffers" as the saying goes. I get it now, the daw and all of the plugins don't have to be synchronized but they do need to be regulated so as not to overfill the asio buffer. I assume the daw does as much as it can without overflowing the asio buffer then stops processing. I guess the problem with clicks is when the daw can't keep up with the cyclic reading of the asio buffer. That's why a long asio buffer helps because that give more time for the daw to process everything. I think a daw does process all tracks and plugins as fast as it can but tries to run slow enough to it doesn't overfill the asio buffer. There might actually be a flag to stop all daw activity when the asio buffer is full. So the processor starts out fast and fills up the asio buffer and then rides on the tail end of the asio buffer, constantly feed it as much data as it can before it is halted again when the buffer is full. So in a sense, it is asynchronous at the start but ends up synchronized to the sample rate of the sound card after the asio buffer is full. The timeline position indicator on the daw is probably fake in relationship to what is actually happening. That about how I picture it because the iteration module can toss out a whole lot of stuff in between samples. At least that's what I think it can do. So if it can do that, it pretty much proves that reaktor doesn't really step thru all of the code one sample at a time. It sure seems like it though when you program in core.

Overfilling the buffers is not an issue, it is trivial to just stop when its full and wait for the next empty buffer. There will be some sort of callback to the host to say the buffer is ready. The problem is not filling them in time, that's why the problem is called an 'underrun' - time is up, the DAW needs the buffer back, but it's not filled yet, so you end up with clicks and pops due to the missing data.