Hello everyone,
 
so far I must say Sonar keeps fascinating me (in a good way),
yet I ran into VERY strange issue, I observed it's not related to a specific computer (doesn't matter if 4 threads at 2.4GHz or 12 threads at 4.3GHz, 8GB ram or 32GB ram etc..), audio interface (Fireface 802 -usb2.0, HDSPe AIO -PCIex) or Sonar version (2016.05, 2016.06),
what happens is that when I record let's say 10 tracks, and then let's say each of those tracks consists of 13 takes, Sonar suddenly starts to crash the audio interface - popup with something like "audio dropout - interface stopped" appears, (always ASIO mode, buffer usually 128 or 256),
what I observed is that it tends to happen more often with higher number of takes, and from certain point the "interface stopped - audio dropout" problem starts to happen even during recording, not only playback,
I am trying to figure out how can amount of takes (which is nowhere as huge) on tracks which are less than 5 minutes long load up the audio interface so much it crashes, does Sonar automatically handle all the takes although they are not actually played at all?
on the other hand, projects with 10 tracks of just 1 take with files bigger than 250MB each are without any problems, which definitely excludes the problem of slow drive or memory/buffer/cache problem in my opinion
 
thanks in advance, any help appreciated

Try increasing the Playback and Record Buffer Size to 256 KB or 512 KB:
 
Preferences>Sync and Caching>File System>Playback I/O Buffer Size (KB) and Record I/O Buffer Size (KB)
 
 

I don't have read or write caching enabled (by default), should I? O.o
in Sonar documentation it's clearly written:
"SONAR will usually perform best with all caching disabled, which is the default setting. If your computer has an older IDE disk controller, or a disk controller that does not use DMA transfers, enabling caching may improve SONAR’s audio performance."

Try tuning the buffers first. Hopefully the projects are not on the system drive.

ASIO buffers are fine, no problems even with buffer just "64", incredibly low roundtrip latency as well,
as I wrote, there is a problem with Sonar somehow trying to push all takes to be processed although they are not actually being played when I am recording another takes in those same tracks -_-
projects aren't on system drive indeed, plus system drive is SSD

I was referring to the disk I/O buffering mentioned msg#2 in an attempt to answer your question in msg#3
I asked about the project location because there was no mention of storage configuration before you last message. Given the projects are not on the system drive, the system drive type does not matter.

Interface stopped? I think I've never heard of such. Do you probably mean (SONARs own) Audio engine that stops by dropouts?
Could this be due to too much stuff piled in Undo history if you're not saving as you go?
Ten 5 minute tracks with 13 takes each means there can be around 2 gigas of stuff depending on the sample rate and bit depth. I see you do have loads of memory, but still? 
In case you do save frequently, just ignore this 2 cents of mine.
 
Btw, IIRC also muted tracks consume CPU cycles, so why not the silent takes as well? Your system is most likely
capable of running 130 tracks, though. Are you recording more than one track at a time? Heavy plugins  in use?

Enabling Read / Write Caching is independent from I/O Playback / Record Buffers,
and should be disabled (as you cited from the manual).
 
But the I/O Buffers have to be capable to stream a portion (buffer) of all tracks and takes in your project simultaneously.
 
In your case that would be 130 Tracks/Takes prepared to be played back, even if some tracks or Take Lanes are muted (because you/we want to be able to unmute Tracks or Takes during playback, so they have to be buffered, too).
 
That's the reason why increasing I/O Playback / Record Buffers should be considered when your project contains a high count of tracks and/or takes.
 
 

not sure if it makes sense, but once I enabled those buffers and put something like 512, it only resulted in (Sonar) metronome severe (tempo) inconsistency and stuttered playback, so that's a no go for me definitely;
 
I usually used to record no more than 15 tracks at once at [link=mailto:44100@16,]44100@16,[/link] often very long segments, there has never been a problem until we started recording multiple takes "over and over" (thanks to marvellous loop recording feature of Sonar btw),
huge I/O buffers are problem because they will introduce more-than-negligible latency, and so unsuitable for recording along tracks+metronome

tzzsmk
not sure if it makes sense, but once I enabled those buffers and put something like 512, it only resulted in (Sonar) metronome severe (tempo) inconsistency and stuttered playback, so that's a no go for me definitely;
 
 

You don't have to enable buffers in Sync and Caching.
If you enabled Read / Write Caching, disable it.
I/O Buffers are important, not Read / Write Caching!