LatencyMon - how to interpret results? [SOLVED]

I've run LatencyMon and have been reading all sorts of things about it. Yet I haven't found any mention of whether I should run it for a few hours by itself, or with Platinum opened but not recording or playing back, or while recording.
 
I get passing results unless I'm recording with Platinum. I have a drum loop setup with Superior Drummer and if I record Ivory as midi and also record the output of my mixer after a minute or so I get the failing grade from LatencyMon with this generic 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 problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates."
 
The biggest problem seems to be with hard pagefaults. I'm trying to track down a problem with Platinum.
In the real world, I'm not getting any other dropouts except in rare instances. I can have lots of audio and midi tracks with lots of FX playing back or recording audio and no problem, no dropouts except rarely. Yet if I'm just sitting there playing my Ivory piano, the audio engine shuts off. And it happens very often, maybe every 10-20 min. It happens also during recording midi, never during playback.
 
Any suggestions on tracking this problem down?

gswitz
I can run Sonar and Netflix and tons of other things on my PC and never go red in LatencyMon.
 
I can run it for hours without issue.
 
Click the Driver's tab and sort by Highest Execution time.
 
Tell us what the Driver Files are that are causing the issue.

With Platinum open but no playback or recording. I see the DPC count for LatencyMon at the top with 39 million followed by USBPORT.SYS at 24 million, next is MOTU midi interface at 16 million, then ATAPORT.SYS down to 284,000.

For ISR count HAL.DLL tops the list followed by USBPORT.SYS, then ATAPORT.SYS

Possible clues:
MOTU midi interface 16 million
Trouble when playing (or recording from) keyboard
 
Possible reason:
MIDI flooding, perhaps from a MIDI loop?
 
Does your MOTU do merging or any other processing (what model is it)? Is your controller configured to merge input with output? Is Sonar set to echo any MIDI back out?

Here you go gswitz
 

 

 
I created the above by starting LatencyMon and then going to Platinum and hit record and played the piano, recording midi and audio for about 20 sec until I got the error message from LatencyMon. It recorded about a minute or so total. I hit stop. I then used the snipping tool to capture the latency Mon window.
 
For the Resource Monitor window I opened a song that had midi and audio and just hit play. My audio is recorded on the D HD. I wasn't able to figure out how to display the processes with disk activity. Let me know if you need that.

If that report in post #7 was running for a minute, the usbport.sys execution time is 42 seconds. That's extreme.
Is it possible to create two different reports, one with playing keys and another without, with stats cleared at the beginning of each? Also, that latencymon report unfortunately doesn't seem to include an elapsed time, so it's up to the experimenter to log the time (unless it's on another page?). (By the way, you're using on-board usb, no adapter card, right?)

Ok here's another test:
turned on latency mon a few minutes, platinum was open, then started playing midi piano, lost piano audio with a dropout of audio engine after about a  1min, I can see audio engine icon on Transport unlit and off, I wasn't recording just playing piano with transport stopped, all was caught on latency mon in this image below. After I hit stop on Latency Mon I looked at "Stats" and copied and pasted the results in report 4.RTF  I'm not sure how much of that text I should put into a forum post, so if anyone wants all or part of it let me know.
 
 

gswitz
So, your USB Latency is a bit high. I'm curious which device is causing it.
 
You can trouble shoot this by starting latencymon and then try unplugging various USB things (including your mouse). Test to see if there is a particular device that is causing it to be high. You see mine is at .18 and yours is at .77.
 
I also noticed ataport.sys...
https://msdn.microsoft.com/en-us/library/windows/hardware/ff551332%28v=vs.85%29.aspx
 
Do you have a an older ATA drive in your system? Just curious.
 
I once had a mouse issue with a logitech mouse. I just had to download Logitech's driver and use that instead of using the default Windows driver which didn't have good latency specs.

I unplugged these USB's  - I-lok Dongle for Ivory, Dongle for Vienna Instruments, USB keyboard (this is 2nd keyboard for vocalists to record themselves in vocal booth). The only other USB is my MOTU midi interface. I unplugged all except the MOTU, opened an old project in Platinum, hit play and got a dropout in a min or so. Sometimes when I first open a project I get a dropout early on and then no more dropouts.
 
I do have an old 80 gig IDE HD that has XP, in case I need to use XP. I have 
440 gig - boot
3T - data
1T - audio
2T - Ivory
220 gig - Win7 for dual boot
 
 For USBPORT.SYS the value for highest execution varies a lot. It's usually near the top of the list.
 I'm not sure what to look for in Latency Mon. This values usually starts around .17 and went up to .25 during the test I have above. It make take a while running the test to make it up to .77.  Let me know what you want me to look for with unplugging these USBs.

Hi, I had similar problem, and I solved Changing Project, Virtual Instruments are not copied either from another computer and midi information very confused, in the piano roll

The USB system used 22 seconds of CPU that time. The number of DPCs for the Motu midi still looks high. With nothing playing, it shouldn't have so much to say. Is there any way to check your system without it? E.g. unplug it and play a project that doesn't send to any h/w synths.

Unplugged all USBs, including midi interface and iLok for Ivory. Since the previous test wasn't very good with Sonar looking for the midi interface and Ivory, this time I Deleted Ivory, Start LatencyMon, then sonar, hit play, runs 5.5 min no dropout, rewind hit play, message comes up saying "no MOTU midi interface should sonar route midi to another and stop transport?" NO.  Plays for a min then dropout, hit play it goes about 3 min and dropout. I have the Stats saved for this one below also.

bvideo
There is no single "highest execution time" to cause a dropout, and now USBPORT is running at a sane level. There is still a lot of disk activity.
 
At this point, the disk is still a possible culprit: ataport.sys has a high ISR and DPC count. Although its total execution time is low, it does show there is a lot of disk activity going on.
 
Has the overall syndrome of your dropouts changed? Earlier you reported no dropouts except when playing or recording from your keys. Now without keys there are still a few dropouts.
 
Did latency mon stop reporting problems? If so, the remaining problem might be disk I/O. For your 32-bit system, paging could be an issue if there are a lot of processes that need to run and compete with Sonar for memory. Or reading samples could be an issue, or reading a lot of audio files. For disk I/O, the Resource Monitor report could be more useful. Also, did you try bitflipper's suggestion to freeze your sample-driven instruments?
 
What audio buffer size are you using now? Does a higher setting help? How about disk I/O buffers? The manual/help has info on how to tune and analyze disk I/O problems (Edit > Preferences > Audio - Sync and Caching, and Edit > Preferences > Audio - Driver Settings
 
Back to the MOTU topic: with the MOTU plugged back in but no equipment connected, is the Latency Mon report more sane? How about hooking up your equipment in small steps, starting with just the P200 out going to the MOTU in. Play a few notes into Sonar for a minute and check the L-M report for high counts from motumidi64.sys. What is the first hookup step that causes crazy USBPORT.sys numbers?

On the Main page for LatencyMon, it always starts off saying no dropouts expected, yet after a few minutes it always says the machine is having trouble. This page always shows hard pagefaults ok at 1st then all the way into the red (the highest value). Today I started a new project, started LatencyMon, imported a mp3, played mp3 had dropout after 2 min. This is not that unusual when I 1st open a project, many times I'll have an initial dropout and then no more for maybe an hour or so.
 
Today after listening to the mp3 and charting the song out. I recorded my Ivory piano track for the singer. I recorded midi and audio at the same time, so I could send him the audio to sing to. 1:15 into this recording I had an audio engine dropout. Then autopunched in and no dropouts until the end of song at 4 min. I have all of my usual USBs plugged in.I did save a snip image of the drivers for this whole episode today and I saved the Stats to a file also. Let me know if you'd like me to post any of that.

 
Yesterday I mixed a song for 45 min with no dropouts. It had about 8 audio tracks, Ivory piano, Superior drummer and a midi bass. These midi tracks weren't frozen. I recorded the output of my mixer back into Sonar and created 3 stereo mixes. So my dropouts have always been at unexpected times even with XP. With Platinum it's much worse than X3 and 8.5 in regard to getting dropouts of the audio engine by playing or recording live midi.
 
I haven't looked at my virtual memory settings in a long time. Total paging size for all drives = 4094. Recommended = 6141. I see I have checked "auto manage paging file size for all drives" Below that I see C drive - system managed. All other HDs - none. I just changed this. I unchecked that box and then chose 6141 as the max and min. C drive is only one with paging file. Let me know if you'd try something different.
 
I do have a 64 bit Win 7. Currently I'm using Sonar as 32 bit, because I'm still preparing to transition to 64 bit Sonar once I get some things worked out with pluggins. Would you suggest me removing the other boot drives - 80 gig IDE XP and 200 gig Win7? It's rare that I dual boot.   How do I do the Resource Monitor report for disk I/O?
 
My record I/O buffer size is 512. and my playback I/O buffer size is 512. I left these like this for a long time. File system unchecked these 2 boxes "enable read caching" and  "enable write caching". Midi buffers are 64 and prepare buffers 500msec. 5.8 msec latency. Next value is 11.6, which I can hear flams with my external synth piano and Ivory. So I need 5.8.
 
I'm not sure what you mean by:
 
"Back to the MOTU topic: with the MOTU plugged back in but no equipment connected, is the Latency Mon report more sane? "
 
Is no equipment connected mean no USB equip? I did a test above similar to what I think you're asking in an above post. I'd be happy to try another test. Let me know.
I'm interested in trying your test with checking the L-M report for high counts from motumidi64.sys. So when you say hooking up my equipment in small steps are you only referring to USBs or HD's.  What would you categorize as crazy USBPORT.sys? What's normal and what's crazy high?
 
Thanks for all your help everyone,

If you have a virus scanner, you might try disabling it for a time and see if it helps.
Windows Defender too. Sometimes these types of programs can add load to your discs at a time when it causes dropouts.
 
If you do find that disabling these programs helps, you can usually specify certain folders for them to ignore (the folders you keep your projects in). This way, you can hope that you can track without the virus scanner re-reading the files to make sure they aren't viruses.
 
It may not help, but worth a try if you are starting to look at your discs.
 
In Latency Mon, the bottom row for me goes up to 11709 and into the red, but it always indicates that my system is good for real-time audio.
 
After you hit stop on the Latency Mon tool, you can read the Stats tab. This should give you a lot of useful information.

gswitz

If you have a virus scanner, you might try disabling it for a time and see if it helps.

Windows Defender too. Sometimes these types of programs can add load to your discs at a time when it causes dropouts.

 

If you do find that disabling these programs helps, you can usually specify certain folders for them to ignore (the folders you keep your projects in). This way, you can hope that you can track without the virus scanner re-reading the files to make sure they aren't viruses.

 

It may not help, but worth a try if you are starting to look at your discs.

 

In Latency Mon, the bottom row for me goes up to 11709 and into the red, but it always indicates that my system is good for real-time audio.

 

After you hit stop on the Latency Mon tool, you can read the Stats tab. This should give you a lot of useful information.

For my DAW I don't have a virus scanner. I'm real cautious about using the internet with it and havne't ever gotten a virus, but I do have Defender enabled. I just disabled it to see if that helps also. I did save the Stats tab on all the posts above. So let me know if you want me to check anything.

gswitz
It didn't help disabling Defender?
 
I'm not sure I have any great ideas.
 
You could post the full text from the Stats tab and see if anyone notices anything. I can't promise I'm going to see anything useful but maybe someone else will.

At this point I'm not sure if it helped disabling Defender, but I think it's worth a try and I'm going to leave it disabled for a while to see. I'm very cautious about using the internet with my DAW.
 
Here's the full text from the Stats tab plus a snip of the Drivers tab. It starts off with my personal notes on what I did and how this report captured 2 dropouts.
 
On the Main page for LatencyMon, it always starts off saying no dropouts expected, yet after a few minutes it always says the machine is having trouble. This page always shows hard pagefaults ok at 1st then all the way into the red (the highest value). Today I started a new project, started LatencyMon, imported a mp3, played mp3 had dropout after 2 min. This is not that unusual when I 1st open a project, many times I'll have an initial dropout and then no more for maybe an hour or so.
Today after listening to the mp3 and charting the song out. I recorded my Ivory piano track for the singer. I recorded midi and audio at the same time, so I could send him the audio to sing to. 1:15 into this recording I had an audio engine dropout. Then autopunched in and no dropouts until the end of song at 4 min. I have all of my usual USBs plugged in.
_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
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 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  1:25:03  (h:mm:ss) on all processors.
 
 
_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name:                                        Q9450
OS version:                                           Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware:                                             EP45-DS3R, Gigabyte Technology Co., Ltd.
CPU:                                                  GenuineIntel Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz
Logical processors:                                   4
Processor groups:                                     1
RAM:                                                  4094 MB total
 
 
_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed:                                   3200.0 MHz
Measured CPU speed:                                   1949.0 MHz (approx.)
 
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.
 
 
_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
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):   2414.919447
Average measured interrupt to process latency (µs):   2.550103
 
Highest measured interrupt to DPC latency (µs):       386.540704
Average measured interrupt to DPC latency (µs):       0.804788
 
 
_________________________________________________________________________________________________________
 REPORTED ISRs
_________________________________________________________________________________________________________
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):              355.56750
Driver with highest ISR routine execution time:       ataport.SYS - ATAPI Driver Extension, Microsoft Corporation
 
Highest reported total ISR routine time (%):          0.073166
Driver with highest ISR total time:                   USBPORT.SYS - USB 1.1 & 2.0 Port Driver, Microsoft Corporation
 
Total time spent in ISRs (%)                          0.121130
 
ISR count (execution time <250 µs):                   9793503
ISR count (execution time 250-500 µs):                0
ISR count (execution time 500-999 µs):                1
ISR count (execution time 1000-1999 µs):              0
ISR count (execution time 2000-3999 µs):              0
ISR count (execution time >=4000 µs):                 0
 
 
_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
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):              293.1050
Driver with highest DPC routine execution time:       nvlddmkm.sys - NVIDIA Windows Kernel Mode Driver, Version 341.44 , NVIDIA Corporation
 
Highest reported total DPC routine time (%):          1.147055
Driver with highest DPC total execution time:         USBPORT.SYS - USB 1.1 & 2.0 Port Driver, Microsoft Corporation
 
Total time spent in DPCs (%)                          1.325890
 
DPC count (execution time <250 µs):                   52275562
DPC count (execution time 250-500 µs):                0
DPC count (execution time 500-999 µs):                5
DPC count (execution time 1000-1999 µs):              0
DPC count (execution time 2000-3999 µs):              0
DPC count (execution time >=4000 µs):                 0
 
 
_________________________________________________________________________________________________________
 REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
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:                 dllhost.exe
 
Total number of hard pagefaults                       5244
Hard pagefault count of hardest hit process:          1072
Highest hard pagefault resolution time (µs):          506774.396250
Total time spent in hard pagefaults (%):              0.165020
Number of processes hit:                              29
 
 
_________________________________________________________________________________________________________
 PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s):                       143.094197
CPU 0 ISR highest execution time (µs):                118.4450
CPU 0 ISR total execution time (s):                   8.187264
CPU 0 ISR count:                                      6275851
CPU 0 DPC highest execution time (µs):                293.1050
CPU 0 DPC total execution time (s):                   87.789829
CPU 0 DPC count:                                      40018822
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s):                       93.313876
CPU 1 ISR highest execution time (µs):                125.290
CPU 1 ISR total execution time (s):                   5.504565
CPU 1 ISR count:                                      1169841
CPU 1 DPC highest execution time (µs):                292.31250
CPU 1 DPC total execution time (s):                   58.252446
CPU 1 DPC count:                                      4077184
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s):                       104.871654
CPU 2 ISR highest execution time (µs):                118.940
CPU 2 ISR total execution time (s):                   5.723335
CPU 2 ISR count:                                      1177015
CPU 2 DPC highest execution time (µs):                209.27250
CPU 2 DPC total execution time (s):                   67.675967
CPU 2 DPC count:                                      4104347
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s):                       81.233991
CPU 3 ISR highest execution time (µs):                355.56750
CPU 3 ISR total execution time (s):                   5.312040
CPU 3 ISR count:                                      1170797
CPU 3 DPC highest execution time (µs):                278.71750
CPU 3 DPC total execution time (s):                   56.947003
CPU 3 DPC count:                                      4075214
_________________________________________________________________________________________________________

Problem solved - I did a clean Win 7 install - Platinum only plus Ivory and Superior Drummer. I recorded piano, bass, and drums on several songs over the last few days, did lots of punching in and didn't have one dropout or loss of focus like I had been having. With the other Win7 install I'd been having a dropout about every 20 min doing this sort of recording, so it looks like this problem is solved.
 
I'm amazed at how fast everything is, Win7 had gotten sluggish. I did very few tweaks, just "no sounds" in Windows, made sure my onboard Realtek audio was playing wav files with Win Media Player, etc, turned off Power Options. I left indexing on for my C drive and left Windows Search on.  As I install others things I need I'll watch things closely and keep making new image files, in case I need to revert.