View Single Post
Old 05-18-2019, 04:21 PM   #25
Human being with feelings
jesus4c's Avatar
Join Date: Jan 2018
Location: Brisbane, Australia
Posts: 70

Originally Posted by foxAsteria View Post
I'm not sure what to suggest, but did you run LatencyMon while running Reaper? The initial results are not always the same as when you're doing DAW work and as you've seen, they sometimes don't crop up right away. If it's running when the problem occurs, it might show you something.

Do you have anticipative fx on? Is the problem related to having armed tracks at all? Sometimes enabling too many cores in prefs/buffering/allow live fx multiprocessing can have adverse effects. Mine's a 16 core and runs best with 2-4 enabled. Many of the settings there can be tweaked when a project is at its limits and you can hear the result immediately if there is a difference.
Not really understanding them, I've only ever glanced at my buffering settings - and have never changed anything. So - defaults all round. Anticipative FX is on. With a render-ahead of 200ms. Nothing else is selected.

ATM, I have no tracks armed at all. And it's rare that I DO have tracks armed. The odd bit of recording into a mic I have plugged into my AudioBox interface or some level control via a control surface is about it. The vast majority of the files I work with are wave files exported from my work system.

I tried running LatencyMon whilst playing my project in Reaper and the results are below (coz, once again, I'm not too sure what I'm looking at) - but, as I was out of the room for a lot of it, I don't know if the stuttering happened or not.

I'll next try running LatencyMon whilst I'm working and quickly have a look when The stuttering happens.

__________________________________________________ __________________________________________________ _____
Your system appears to be suitable for handling real-time audio and other tasks without dropouts.
LatencyMon has been analyzing your system for 0:27:54 (h:mm:ss) on all processors.

__________________________________________________ __________________________________________________ _____
__________________________________________________ __________________________________________________ _____
Computer name: PODCAST-PRODUCT
OS version: Windows 10 , 10.0, build: 17134 (x64)
Hardware: ASRock, H370M-ITX/ac
CPU: GenuineIntel Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz
Logical processors: 6
Processor groups: 1
RAM: 16304 MB total

__________________________________________________ __________________________________________________ _____
__________________________________________________ __________________________________________________ _____
Reported CPU speed: 30 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): 472.405414
Average measured interrupt to process latency (Ás): 5.136931

Highest measured interrupt to DPC latency (Ás): 451.584077
Average measured interrupt to DPC latency (Ás): 1.673198
jesus4c is offline   Reply With Quote