tenfoot

Fabio Rubato

tenfoot
Hi Alan. Unless you have massive track and synth counts, as others have suggested I would certainly look into what might be causing issues outside of your system specs. In my experience there is certainly a sliding scale of hardware expense vs return performance in Sonar as you move into very highly specd systems. You already have some fairly decent grunt there.
 
On the other hand if you don't mind the increasing expense for lessening returns, more power to you! :)

Thanks Bruce. Yes, that's the trade-off apparently. I think that I'll probably just persevere for a time until something comes along that'll really outshine Sandy Bridge. I remember that around 10-odd years ago, my then 2/4 core and 4mgs of memory started crying as my projects became bigger. I had apparently started to outgrow it with new software coming through and trying to aim for higher quality. Seems to be pointing that way now a bit. Cheers.
 

I know just what you mean Alan. I have an older quad core i7 processor than yours and I am starting to feel the pinch now. I too use some large Kontakt libraries. FWIW I find spreading the sounds/parts accross multiple instances of kontakt gives me far more even core usage and no performance disadvantage over loading multiple sounds into a single instance. It is also handy when freezing synths or bouncing to audio.

Yeah mate, have read this recently and am adopting. Shame that though, as it took me a while to learn how to do all in one place, which initially looked like a cool way of managing Kontact in one place. 

I also have a 2600k, 16G of RAM. OC'ed to 4.2 . I had a problem with a couple of Vsti's dropping out, crackling  etc. It was suggested that I get a faster sample hard which did solve the problem. I can have multiple Vsti's running and record all day long with 64 Asio buffers, and will often record at 32 buffers. This is via FireWire and a Mrx16 interface. So for me the change in he sample drive breathed new life into my system.
Edit: moving to Windows 10 actually improved the performance much to my surprise. 

scottfa
I also have a 2600k, 16G of RAM. OC'ed to 4.2 . I had a problem with a couple of Vsti's dropping out, crackling  etc. It was suggested that I get a faster sample hard which did solve the problem. I can have multiple Vsti's running and record all day long with 64 Asio buffers, and will often record at 32 buffers. This is via FireWire and a Mrx16 interface. So for me the change in he sample drive breathed new life into my system.
Edit: moving to Windows 10 actually improved the performance much to my surprise. 

Thanks for the suggestion. In particular with the NI Session Horns Pro where I had the sounds drop out, the library - Komplete Ultimate - was installed on my SSD. So I'm thinking that yeah, if indeed I installed the library on my storage 7200 rpm drive, then this could be the issue. However, its on my SSD, so it should be plenty fast enough for access the sounds. 
 
In the initial stages I can record at low ASIO buffers, but building the track and then adding FX, I'm regularly at the top end.

Xeon CPUs are not the best choice for a DAW.
You'll see no audio related benefit from using them.
In fact, they're often running at lower clock-speed... meaning you'll pay significantly more AND take a performance hit.
 
While on the discussion of Mac Pros:
Many folks don't realize this... but the latest generation iMac with Skylake 6700k CPU will *outperform* the $4000 Mac Pro (because it's running Xeon CPU and architecture that's older/slower).
 
Mac or PC, you don't want to sacrifice clock-speed for more CPU cores.
In an ideal situation, you want fast clock speed *and* more CPU cores.
If you have to choose one over the other (and there's a significant difference in clock-speed), go with the higher clock speed.
 
Adding additional unused RAM will buy no additional performance.
You need enough RAM to run the desired projects... to ensure the system doesn't become RAM-starved and start hitting the VM swapfile in lieu of physical RAM (which kills performance).
 
If you're in a situation where disk-streaming sample libraries are bogging down the machine:
A single SSD sustains over 500MB/Sec.
If you need higher disk-streaming polyphony... and the library only allows a single location (EWSO), you can put a pair of SSDs in RAID-0.  This nets about 1000MB/Sec.
If you need insane disk-streaming polyphony, you can run a PCIe (or M.2 Ultra) SSD drive that uses 4 PCIe lanes and sustains 2500MB/Sec.  If you're an extreme composer, you can combine several of these solutions.
A modern well-configured machine can sustain over 4000 stereo disk-streaming voices of polyphony.
If that's not enough... you can run a second "slave" VE Pro machine (dedicated to running sample libraries).
 
Research... to ensure you're getting what you need.

Jim Roseberry
Xeon CPUs are not the best choice for a DAW.
You'll see no audio related benefit from using them.
In fact, they're often running at lower clock-speed... meaning you'll pay significantly more AND take a performance hit.
 
While on the discussion of Mac Pros:
Many folks don't realize this... but the latest generation iMac with Skylake 6700k CPU will *outperform* the $4000 Mac Pro (because it's running Xeon CPU and architecture that's older/slower).
 
Mac or PC, you don't want to sacrifice clock-speed for more CPU cores.
In an ideal situation, you want fast clock speed *and* more CPU cores.
If you have to choose one over the other (and there's a significant difference in clock-speed), go with the higher clock speed.
 
Adding additional unused RAM will buy no additional performance.
You need enough RAM to run the desired projects... to ensure the system doesn't become RAM-starved and start hitting the VM swapfile in lieu of physical RAM (which kills performance).
 
If you're in a situation where disk-streaming sample libraries are bogging down the machine:
A single SSD sustains over 500MB/Sec.
If you need higher disk-streaming polyphony... and the library only allows a single location (EWSO), you can put a pair of SSDs in RAID-0.  This nets about 1000MB/Sec.
If you need insane disk-streaming polyphony, you can run a PCIe (or M.2 Ultra) SSD drive that uses 4 PCIe lanes and sustains 2500MB/Sec.  If you're an extreme composer, you can combine several of these solutions.
A modern well-configured machine can sustain over 4000 stereo disk-streaming voices of polyphony.
If that's not enough... you can run a second "slave" VE Pro machine (dedicated to running sample libraries).
 
Research... to ensure you're getting what you need.

Thanks for that Jim...some great ideas there and yes, I take your point on clock speed vs cores. The M.2 Ultra would need a new mobo but yes, some amazing speed I've seen from that technology. The PCIe is however achievable on my stetup. I have a 1T SSD EVO - fairly new - and it's been a real boot to my setup. The 'slave' VE Pro machine looks fascinating - and no doubt big dosh - and I'll look into that. Thanks for the ideas.

Alan,
I would research your EVO SSD and see if it suffers from the read latency problem for TLC Flash cells.
Not sure if the 1TB's do.  Also not sure if they fixed it via firmware. IIRC, the first fw fix attempt was a failure. It was a big deal until last summer and then poof..gone.
A sample library would be worst case for this issue since it manifests itself as static data ages. 
Here is some info.
http://techreport.com/new...-slow-to-read-old-data

microapp
Alan,
I would research your EVO SSD and see if it suffers from the read latency problem for TLC Flash cells.
Not sure if the 1TB's do.  Also not sure if they fixed it via firmware. IIRC, the first fw fix attempt was a failure. It was a big deal until last summer and then poof..gone.
A sample library would be worst case for this issue since it manifests itself as static data ages. 
Here is some info.
http://techreport.com/new...-slow-to-read-old-data

Thanks for that. It could be related to my experience with Session Horns Pro. Hard to know. There does seem to be a problem in this area with the 2T EVO's but I haven't seen it with the 1T - fingers crossed. Yes, apparently was an issue with the 840's...wouldn't be surprised mind you. Cheers.

I upgraded to a third generation i7..used computer.  Cheap upgrade for what is truly astounding capability.  All my trouble disappeared.  I also got a USB 3 interface.  Good luck.

It sounds like you are good for a while.
I have a 990X from 2011 an it is still running great, so I will keep it.
On an off-topic but humorous note (at least to me)  - I remember buying a laptop in 1988.  It had a 20 MG hard drive.  Yes 20 MG hard drive.  The sales guy said I would not be able to fill up that hard drive in a lifetime!   
Now a lot has changed since then, but  I wonder if we have reached the years where the changes are starting to have diminishing returns for the investment?
Cheers!

I posted this awhile ago but I have found if you set MAX THREADS to one or two below the physical threads you have, it actually improves the performance in SONAR.  I don't know why for sure but my guess is that when SONAR gets ahold of all your threads, the OS cpu needs get bottled necked and performance on the whole system starts to suffer.
 
As un intuitive as this is, it actually worked for me with my 4 core/8 thread system.  I now use a 6 core/12 thread system in which I have max threads set to 10.  When I had the 8 core system, I have the max thread count set to 6. To long of a story on how I stumbled upon this but I was having performance issues and trying everything to fix them and this was a serendipitous discovery.
 
This has worked for many SONAR users (some with more technical knowledge than me for sure) and it also reduced the "core 1" higher usage for many as well.
 
One would think that if there is some technical reason that this works that the BAKERS would reserve one thread for the OS and not let Sonar grab all available cores/threads so no users would have to deal with this.
 
Try it and see if it helps.  This setting is in the INI file and the exact parm name will be self evident once you look at the list of parms that you can change.  This setting is in the same area as the thread scheduling parm.
 
Hope this helps again for you and good luck,
 
Jim