[Solved] Dropouts in Sonar X3

After disconnecting the mixer:
 
_________________________________________________________________________________________________________
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 or more ISR routines that belong to a driver running in your system appear to be executing for too long. 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 0:01:42 (h:mm:ss) on all processors.

_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: RICKYSLAPTOP
OS version: Windows 8 , 6.2, build: 9200 (x64)
Hardware: Satellite S855, TOSHIBA, Portable PC
CPU: GenuineIntel Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
Logical processors: 8
Processor groups: 1
RAM: 8076 MB total

_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 2395.0 MHz
Measured CPU speed: 2026.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): 303.620309
Average measured interrupt to process latency (µs): 5.150816
Highest measured interrupt to DPC latency (µs): 280.100426
Average measured interrupt to DPC latency (µs): 1.251752

_________________________________________________________________________________________________________
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): 562468.767850
Driver with highest ISR routine execution time: i8042prt.sys - i8042 Port Driver, Microsoft Corporation
Highest reported total ISR routine time (%): 0.167453
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in ISRs (%) 0.127490
ISR count (execution time <250 µs): 579501
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
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): 362.288935
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total DPC routine time (%): 0.186164
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in DPCs (%) 0.225216
DPC count (execution time <250 µs): 756767
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 1611
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: chrome.exe
Total number of hard pagefaults 83
Hard pagefault count of hardest hit process: 75
Highest hard pagefault resolution time (µs): 1192702.685595
Total time spent in hard pagefaults (%): 0.199579
Number of processes hit: 3

_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 7.754258
CPU 0 ISR highest execution time (µs): 562468.767850
CPU 0 ISR total execution time (s): 1.040316
CPU 0 ISR count: 579502
CPU 0 DPC highest execution time (µs): 362.288935
CPU 0 DPC total execution time (s): 1.805143
CPU 0 DPC count: 754556
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 3.571119
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 22.560752
CPU 1 DPC total execution time (s): 0.000115
CPU 1 DPC count: 40
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 1.483513
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 151.631733
CPU 2 DPC total execution time (s): 0.012879
CPU 2 DPC count: 1324
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 2.906584
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 25.059708
CPU 3 DPC total execution time (s): 0.000290
CPU 3 DPC count: 80
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 1.689829
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 154.588309
CPU 4 DPC total execution time (s): 0.010349
CPU 4 DPC count: 1172
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 3.022037
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 28.325678
CPU 5 DPC total execution time (s): 0.000620
CPU 5 DPC count: 150
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 1.590594
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 149.844676
CPU 6 DPC total execution time (s): 0.008177
CPU 6 DPC count: 996
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 2.968890
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 19.546973
CPU 7 DPC total execution time (s): 0.000194
CPU 7 DPC count: 60
_________________________________________________________________________________________________________

Are you trying to do everything on the 5400RPM system drive?

I do have access to an unused 7200RPM, 320GB, USB 2.0 external drive. Would that take the load off my system drive?

I'll play around with the buffers and then give the external drive a shot if the problem persists. If I were to connect the external drive, which components should I move over to it?

I would try to record to the external drive. Nothing needs to be moved, just some config changes in SONAR

• "Project Files" in Project > File > Folder Locations and
• "Global Audio Folder" in Project > File > Audio Data

should be pointed to a directory on the external drive.
 
One thing to keep in mind when relocating the "Global Audio Folder" to removable media, if the drive is not available when SONAR starts up, the program will automatically revert the "Global Audio Folder" setting to "C:\Cakewalk Projects". It will not revert back to the external drive when it becomes available, it must be manually reset.

If the machine is not recording well at 44.1 what would be the benefit of changing the sample rate to 48?

44.1 k or 48 k - either one is fine.  I was too lazy last night to add 44.1 k, and additionally there is not much of a resource bump needed between one or the other of those, so why not go with 48 k?
 
But, again, you were correct that 44.1 k is also a fine choice.
 
I would hope that some local environmental issue is at work on this computer, causing the dropouts, because then we should be able to ferret it out.
 
Please DO list the Sonar-reported Total Roundtrip Latency value, from Edit>Preferences>Audio>Driver Settings, with the settings set to as I posted above (sample rate of either 44.1 or 48 k, ASIO Buffer Size of 128, Sonar Driver Mode of ASIO).
 
And, as Cactus posted above, I too had problems with the battery management devices in my gigging laptop, and I had to disable that stuff to avoid massive latency spikes.
 
Also, extra devices, such as COM 1 port, can be disabled, as it is a vestigial leftover for most folks, from way long ago.
 
I also agree that generally the whole background/foreground services tweak is not needed from Windows 7 on up.
 
Bob Bone
 
 

Off-the-shelf laptops are often problematic when used as a DAW.
Let me explain why (it's pretty logical when you break it down).
 
A typical laptop is designed for the "general purpose" end user.
That user is surfing the Internet, using Facebook, sending Email, running Office applications, maybe light photo editing, listening to MP3s, etc.  None of these tasks are particularly taxing.  The general-purpose user is much more concerned about battery-life than how well the machine sustains heavy loads in timing critical applications.
 
When you're dealing with ultra-tight space (small form-factor machines - which a laptop is an extreme example), performance compromises *have* to be made to keep temperature in check.
Notice that clock-speeds of mobile CPUs haven't gone up much the past ~5 years.
Power-management and CPU throttling help keep temps in check.
 
 
Off-the-shelf laptops often use motherboards where the majority of BIOS parameters have been blocked.  
This is done to keep tech-support issues to a minimum.
The general-purpose user will never notice DPC Latency spikes... or a 2ms hiccup in data flow.
When running ultra low-latency audio, those settings can make a huge difference.  
If there's a 2ms hiccup in data flow and your ASIO buffer size is 1.5ms, you're going to experience a drop-out.
There's not much you can do in this case.  The BIOS parameters you need aren't exposed.
 
All that said, some laptops are certainly better than others.
Custom built laptops tend to fair a lot better... as you at least have some control over the components used... and additional BIOS parameters are available.  Even with the best laptops, you're making performance compromise compared to a fast tower.
 
To summarize:
To effectively work at ultra low-latency, your machine needs to be able to (indefinitely) sustain heavy loads (processing and disk) without hiccups.
Those requirements are exactly the opposite of a general-purpose user.
 
 
 

Ok, so the round trip latency reported by Sonar is 101.9msec, 4495 samples. I've got sample rate set to 44.1kHz. Driver is set to ASIO. My ASIO panel (in Scarlett MixControl, with the Focusrite 18i20) only gives buffer size options in terms of msec 1-20, so the ASIO buffer size in MixControl is currently set to 20msec. Sonar says that ASIO buffer size is 20msec, 883 samples. The fast/safe buffer size slider in Sonar is faded and I am unable to move it. It's currently stuck all the way at the fast end. I wish I could share a screenshot of the page to make it clearer, but I don't have it posted at any url that I could pull it from.
 

I also attempted to record to the external hard drive I mentioned earlier. As I said, it's a usb 2.0 drive. I only have one usb 2.0 port on my computer, so I used a usb 2.0 four port hub to connect both the Focusrite 18i20 and the external drive to that port. This failed to resolve the dropout problem.

See!  both of what I said originally, Jim backed me up too on the "Laptops are problematic" theme. 
 
Until you test for DPCLAT your working blind. your reading is not good at all, My old 2004 Toshiba laptop runs a 50ms, My wife's Lenovo about the same. 300ms is about as High as I would ever want happening. Now you need to figure out what it is that is hogging your resources. Did you try the battery management? 
The Scarlet Mix control should be fine at 10. Even on half the computer you have. 
 

Jim Roseberry
Off-the-shelf laptops are often problematic when used as a DAW.
Let me explain why (it's pretty logical when you break it down).
 
A typical laptop is designed for the "general purpose" end user.
That user is surfing the Internet, using Facebook, sending Email, running Office applications, maybe light photo editing, listening to MP3s, etc.  None of these tasks are particularly taxing.  The general-purpose user is much more concerned about battery-life than how well the machine sustains heavy loads in timing critical applications.
 
When you're dealing with ultra-tight space (small form-factor machines - which a laptop is an extreme example), performance compromises *have* to be made to keep temperature in check.
Notice that clock-speeds of mobile CPUs haven't gone up much the past ~5 years.
Power-management and CPU throttling help keep temps in check.
 
 
Off-the-shelf laptops often use motherboards where the majority of BIOS parameters have been blocked.  
This is done to keep tech-support issues to a minimum.
The general-purpose user will never notice DPC Latency spikes... or a 2ms hiccup in data flow.
When running ultra low-latency audio, those settings can make a huge difference.  
If there's a 2ms hiccup in data flow and your ASIO buffer size is 1.5ms, you're going to experience a drop-out.
There's not much you can do in this case.  The BIOS parameters you need aren't exposed.
 
All that said, some laptops are certainly better than others.
Custom built laptops tend to fair a lot better... as you at least have some control over the components used... and additional BIOS parameters are available.  Even with the best laptops, you're making performance compromise compared to a fast tower.
 
To summarize:
To effectively work at ultra low-latency, your machine needs to be able to (indefinitely) sustain heavy loads (processing and disk) without hiccups.
Those requirements are exactly the opposite of a general-purpose user.
 

Great explanation. Do you have any idea whether running a MacBook Pro with Boot Camp would perform better that an off-the-shelf Windows laptop of comparable cost?

I was able to successfully record 16 simultaneous channels of drums both with and without the external drive, with the MixControl ASIO buffer set to 20msec, and the playback and recording buffer sizes in Sonar both set to 1024, and the Dropoutmsec variable set to 1000.
 
In every scenario that I've set up however, both with and without the external drive, the data from my LatencyMon tests consistently point to the USBPORT.SYS driver file (USB 1.1 & 2.0 Port Driver) as the biggest issue, with the highest execution in msec.

Yes. The disk buffers in Sonar's Synch and Caching.
I believe the issue needing be addressed is my DPC latency. The Sycon DPC Latency Checker is still reporting latency greater than 1000 microsec, even when Sonar is not in use.