I'm no LatencyMon expert, either, but that seems fine. Did you check CPU speed in Resource Monitor? When I first fired up my new machine Speedstep/Windows was running the CPU at less than 1GHz.

Yeah, wdf01000.sys is the "auto-detect" functionality of a wi-fi adapter (pings like every 4 seconds), and EVERY computer user - DAW or not - should highly consider disabling that guy. (It should have been named "WTF01000.sys" for DAW users!).
 
Please see this post - the first link in there tells you how to nuke that one.

Thank you for all the thoughtful advice. I found one strange issue related to power-settings that I thought I'd share:
 
I first checked the event logs (and cleared them just in case), all drivers, made sure the Microsoft Defender was leaving my folders alone, no indexing, etc. Then I confirmed that my power settings were set to "maximum performance". I rebooted and intended to check BIOS. Interestingly, I got a BIOS warning that my computer was booting from Hibernation (even though Hibernation was selected as OFF in Control Panel). I left the BIOS alone and booted into Windows. Confirmed that my power settings were indeed "maximum". I deleted the power profile and recreated it as "maximum performance". I again confirmed that Hibernation was off, rebooted and could confirm the BIOS without the warning. So I'm now pretty sure that something related to power settings had activated Hibernation even though it was off in Control Panel. I've never seen that problem before, but worth noticing.
 
I do not have WiFI, but even turning off Ethernet (Intel PCIe Gig) made no difference. LatencyMon did not reveal anything to me and seems to indicate that my system is capable of Realtime audio.
 
I also tried creating a bundle (.cwb) and restore from that - no difference.
I tried increasing my ASIO buffers from 50 ms to 100ms - no difference.
 
Next, I'm going to remove each VST one at a time, and see if I can find the root cause.
 
There was one setting in Sonar that I could not make work, I'll document that next.

I have one setting that is greyed out in settings, that came up in the help files:
 
Pref -> Audio -> Driver Settings -> Mixing Latency
- "Buffers in Playback Queue" is greyed out containing a "2"
- "Buffer Size" slider is greyed out with a setting of "Fast" (all to the left).
 
Q: does anyone know why it's greyed out?
 
Thanks
 

They are disabled in ASIO driver mode. The ASIO client software is used instead.

thank you - that makes sense.

I began archiving tracks, and one of the Miroslav Phil 2 tracks did the trick. The track was even muted, but setting archive on both the VST and the midi track lowered CPU by 20% and playback is now pretty much back to normal, but with a 100 ms ASIO buffer (96k)
 
I had forgotten that MP2 received an update on 2/16, so my goof for not recognizing that and blaming it on Newburyport
 
 
 
 

I was having the same issues. I did find a helpful solution for one of them.
 
1. There were significant dropouts, which impacted recording. Very significant and very disconcerting. The dropouts were added during recording but not added during play.
After trying the normal "increase the buffer size" stuff, I don't know what it was, but something caused me to think "stutter" during a file write operation - e.g, disk access.  I moved the song to my SSD drive and instantly, the recording stuttering issues went away.  I went back to the regular hard drive, and stutter back. Tested again on the SSD and no stutter.
 
Nothing else changed in my i7 Win 10 16 Gig system with ASIO audio drivers and a PCI connection. The conclusion is that something in Newburyport was performing poorly during write operations. My SSD was fast enough to keep up with it.  But my hard drive, which has been the same one I have used for many songs, suddenly could not be written to fast enough.
 
My SSD isn'tthe largest drive so I have adopted a "current song only" approach, offloading the song onto a regular drive when done.
 
I *STILL* do have other kind of cracks and pops issues hat I did not used to have, and they seem to be as of late, but they are minor and tolerable compared to the stutter issue I faced.
 
2. I do find that VST's... less than I historically have used... put a rapid strain on the system. I freeze tracks quicker than I would like to, but that doesn't help the scenario where the VST is on a bus or an aux track.
 
I am hoping Cake is looking into these kind of issues.
 
Rick
 
 
 
 

rickidoo
I moved the song to my SSD drive and instantly, the recording stuttering issues went away.  I went back to the regular hard drive, and stutter back. Tested again on the SSD and no stutter.

Review my comments in post #5, changing the cache size might be all you need to do.

Rick - thank you for posting your findings.
 
After more studying with SysInternals I also concluded that there is something about disk I/O that's far less efficient in Newburyport, at least on my system. I've ordered a small 128 G SSD that I'm going to move my projects to, and see if that makes a difference.
 
Sampletank historically has had problems with the VST3s, and I've always used the VST2. For Miroslav Phil 2, and the "worst" project, I'm using the VST3, so that's another thing to consider for me.
 
Generally, my experience has been that Sonar is incredible efficient under load, so something is definitely different for me. I do know that system performance doesn't degrade gracefully (i.e. linearly) as load goes up, but it was such a dramatic change after Newburyport, that I chose to post.
 
I'll post if I notice anything else of significance.