Hi all,
Within the Cubase forum are multiple discussions about latency
and how this can affect using Cubase and your daily work.
I’m running now on Windows 11 pro, latest updates and Cubase 13.0.41,
using a Steinberg MR816csx connected by FW. The system is running without any problems, no stutter, hick-ups or other weird problems. Using up to 250 instrument, Group and FX channels.
When I look to my LatencyMon results I should have big problems, but I don’t. I try to understand why?
Hi,
Probably you don’t stress your computer with a large project and/or heavy plug-ins.
yes I’d say it is quite incredible that you can record without clicks and pops. You are one of the lucky ones I guess.
Maybe Firewire bypasses all other problems 
?
what power scheme are you running, and what computer hardware are you using?
250 VST instruments sounds pretty significant to me, but what do I know?
@TwanV What audio buffer setting for you audio interface do you use?
Mainboard Gigabyte Z790 Aero G rev 1.0, bios update 12F.
Processor Intel I9-13900K.
Memory TeamGroup DDR5 96gb, running at 6000MHZ.
M2 Kingston Fury Renegade, read 7300mb sec, write 7000mb sec,
3 x 2TB and 1 x 4TB.
Videocard Asrock RX 6600 XT challenger 8gb oc.
Hi mlib,
what I see 256?
Hi Martin,
Thanks for your reply.
This could be, but why? Hardware, software or combination?
Depends on the plugins in use. There are VSTs out there pretty light, while there are others which can really torture our systems with 1-2 instances loaded. At the same time, apart from the VST Instruments loaded, there are whichever VST Effects we load in our inserts/sends. Again, many VST effects are very light while others (especially some used for mastering purposes) can give us a hard time. Just some points to consider.
Hi TwanV,
As far as I know, the latency measured in latency monitor is not the audio latency measured in cubase or audio interface. Is the IRQ latency, some kind of hardware latency of your computer when managing data trough internal components (PCIe cards, HDD, etc.). Notice that it is measured in microseconds, and the audio latency (the delay when processing plugins, etc.) is measured in milliseconds.
It shouldn’t be a problem if your system is running as expected, as you can see. Anyway, you can also try to optimize that internal IRQ latency in your system. It’s all about the computer sharing internal resources for different components (e.g. the video card sharing resources with the firewire card).
My guess is that your firewire card is sharing PCI resources with another hardware device thought the same assigned IRQ adress.
… but I insist, not a problem if your audio is working as expected…
Interrupt latency is not the audio latency we use to talk about, although it could be related if a problem is detected.
Hi JoanH,
Many thanks for your explanation!
I’m going to check settings.
I’d be inclined to leave well alone.
Is anything (cubase, background tasks etc) running when you ran latencymon for those results?
If no and results are correct note that you may still be ok with higher buffer settings…but might struggle with lower latencies.
Also you may just have a single dpc spike during that ten minutes test so Cubase may appear to run well but with an occasional spike you could still end up with glitches or clicks in audio recordings if you’re not careful.
Hi Grim,
Nothing is running.
Hi @TwanV , While your DPC numbers are on the high side, they’re still under 1ms and should be OK for audio processing (obviously, since you’re not seeing any problems).
The (apparent) problem number here is Interrupt to Process Latency (IPL). This is a measure of the time it takes for a process to wake up after an interrupt is completed and control passed back to the process.
Latencymon can’t measure this directly for currently active external processes, so it spawns a synthetic process of its own which initiates an interrupt and, once completed, measures the time taken for the process to return to active state. This activity is repeated for as long as the Latencymon session runs.
I’ve seen the behaviour you’re reporting on a couple of our 12th and 13th gen machines. In both cases there was no impact on audio processing.
The telltale seems to be that the longer Latencymon is running, the higher the IPL number will go. On one occasion, I let Latencymon run long enough that the IPL number reached over 1 second, which is ridiculous. Any machine that really had that kind of internal processing delay would grind to a halt very quickly.
So, the issue seems to be that Latencymon has problems with IPL measurements on Intel hybrid core processors under certain circumstances.
Out of curiosity, we installed Park Control by Bitsum (free) and used it to turn CPU core parking off. This got rid of the silly IPL numbers we were seeing on Latencymon.
If you’re curious, you can give it a try. I’d be interested to see if it affects the Latencymon report on your machine.
