100+ Millisecond Block Size?

[cturner]

Greetings-

Like many others, I'm chasing an audio glitch.

Windows 10 homebuilt with an Asus PS10SWS motherboard, MOTU Ultralite Hybrid MkIII through a TI chip Firewire interface. My Reaper 24/48k project uses multiple VSTi, and multiple copies of some VSTi, such as AAS Chromaphone.

I get an infrequent audio glitch, perhaps once a minute or so. Less frequent at 512-1024smp block size, more frequent at 128 samples. I've spent a fair bit of time optimizing the latency of my computer. LatencyMon suggests it's adequate with highest DPC time of 136µs for the nVidia 960 driver. I get the glitch if I recreate the project in Bitwig.

This morning I decided to set Reaper to use the dummy audio interface, and I get the same behavior.



You can see the performance meter "RT longest-block" hit 114.01ms. I have to admit I don't really know what this is saying. I assume that the 2.67ms is Reaper's latency with a 128smp block size and the 114.01ms is what it's dealing with ATM.

My question is whether, considering I can reproduce the audio glitch using the dummy audio device, my problem is with some VSTi, or some combination of VSTi?

Does anyone have any thoughts or suggestions? I'd be greatly appreciative!

Best, Charles

[cturner]

Greetings-

I did finally track down my issue to the VST3 implementations of the McDSP plugins I have: ML4000, Filterbank and Analog Channel. They've acknowledged the issue and will release a fix in the future.

In the meantime, my McDSP VST2.4 incarnations are trouble-free.

Still wondering about the "RT longest-block" monitor. Can anyone explain what it's showing? Also something about Reaper's Dummy Audio device. Where does the audio go?

Best, Charles

[Xenakios]

Originally Posted by cturner

Reaper's Dummy Audio device. Where does the audio go?

Nowhere. It's just a special silent mode, I suppose for testing purposes and for people who use Reaper only to drive external MIDI devices.

[vanhaze]

Originally Posted by cturner

Greetings-
Still wondering about the "RT longest-block" monitor. Can anyone explain what it's

Ok, so you see 2 values, divided by a "/" symbol.
The left value is the time Reaper needs at any given moment to succesfully process audio in realtime, without the chance of an audio drop out.
The value to the right is the maximum time, given to Reaper, to produce audio in realtime, without an audio drop out.
This value depends on the buffersize, set in Reaper.(the higher buffersize, the higher this value).
Now, if left value in RT longest-block" monitor becomes higher than right value, you get audio drop outs.

[cturner]

Thanks both of you for your kindly replies!

So if I'm reading both your responses correctly, Reaper is given a time interval by the OS to hand off a block of audio data for conversion. This time interval can be found to the right of the "/" of "RT longest block" readout on the performance meter. The left hand number is Reaper's internal calculation of how long the current RT block took Reaper to calculate. (It has nothing to do with audio driver latency at the ISR or DPC level.)

So if the left number is bigger than the right number, there's a glitch, but the source of the problem is internal to Reaper's world. It's not a problem at the audio driver level.

Finally, the dummy audio driver presents an ideal driver of a chosen data rate and block size to Reaper. It's internal to Reaper, and not something installed as an OS driver. So the dummy driver performance isn't affected by latency issues like the nVidia driver hogging ISR/DPC time, etc., etc..

So one can check the right-hand number against the interval block-size at sample rate. If that's correct, then if the left hand number is greater than the right, Reaper's having trouble with RT rendering. If the left hand number is equal to or less than the left and there's a glitch, the source is outside of Reaper.

Do I have it correct?

Best, Charles