Significant performance problems since newburyport

AllanH
I'm not sure if the following is related my recent upgrade to "Newburyport": Pretty much all projects now have significant pops, crackles, and I constantly get "Audio Dropout - the Audio Engine has been stopped unexpectedly". I have to reset the audio engine but upon resuming playback it promptly locks up again.
 
It also seems like the "resting" CPU utilization is far higher than before.
 
I believe this to be "new", as projects that worked fine "as is" on prior releases seem to exhibit the issue.
 
So I've resorted to bouncing the majority of my busses, which I've never had to do before.
 
Q: have anyone else seen something like this?
 
I'd like to troubleshoot a bit before submitting a bug report.
 
Thanks in advance for any thoughts.
 
Allan

A few things to start troubleshooting:

Have you rolled back to Manchester to make sure "Newburyport" is the actual cause? 

When you say "I have to reset the audio engine" , is that by that exiting Sonar, renaming your AUD.ini file and restarting sonar? 

Have you confirmed you have the latest drivers for your audio interface and other hardware (including video card)?

I'm having the same issue. This is a pic of my system idling at 1024. I just updated to the rig signature less than a month ago. I was under the thought that this system would run full mixes with soft synths running and a mess of plugs at 32/64 samples. Not even close. This was a update from a P8P67 3.11 mobo and 1155 socket. I have to disable all plugins to get it to run at 64 samples, which is the lowest in Twin USB's console 2. I've been trying to the point of exhaustion to figure out why it's no better than my old system whatsoever. After spending $600 and pick up the Twin USB to do it.
 
There are so many processes running, and I have no clue what most of them are. I don't use wifi, so that's 'one down' - out of 61! How do I find out what processes should be turned off for audio applications in Win 10?
 

jshep0102
I just updated to the rig signature less than a month ago.

Same advice; check your DPC Latency:
 
http://www.resplendence.com/latencymon
 
If its not high/spiking, then other processes/drivers are not the issue. If it is high, it could be motherboard drivers as well as other hardware. If the board has WiFi and/or Bluetooth, you'll want to turn those off in BIOS.
 
And, of course, make sure your CPU is running at full and fixed speed. Disable Speed Step, C-States and Turbo Boost in BIOS, and set a the High Performance power management profile in Windows. Then go to Task Manager > Performance > Resource monitor, to verify your CPU is running at 4.0GHz, and no cores are parked.

I had similar issues after upgrading to windows 10. My motherboard uses an Intel NIC chipset. I cant remember which it was, but after the update I either had to Install the full driver, or uninstall it and revert to the MS provided driver to stop dropouts and pops/clicks. I wish I could offer more assistance, but this is all I can recall atm.

if you google that worst driver there's plenty of info https://www.google.co.uk/#q=wdf01000.sys+latency

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.

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
 

thank you - that makes sense.

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
 
 
 
 

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.