mettelus
Good drivers will allow SONAR to shift sample rate to conform to the project, so that is why it keeps jumping back up.
 
Bfly's point about "excessively high" is a good one, since extreme values in either direction can cause pops/crackles.
 
The only other things that stuck out is 1) can you lower the latency from 40ms in the FIREBOX UI? and 2) you do not have "Use ASIO Reported Latency checked. I am not sure if that checkbox is forcing the FIREBOX to a higher value on you (never tried that myself, but seems unlikely). The "issue" is the interface is sending SONAR an offset of 8364, but you are telling SONAR to use 0.

I can lower the latency. The only reason I had it so high in the picture was that it was the last setting I tried in order to fix the problem. I tried both checking and unchecking the use reported latency and it didn't seem to make any difference. The lower smaple rate though seems to have fixed the issue.


Again thank you for everyone's replies.

mettelus
 2) you do not have "Use ASIO Reported Latency" checked.

Good catch. That should definitely be enabled, especially when running a large ASIO buffer. It won't affect anything that happens in real time, but it ensures that all of the input latency is compensated after the fact by sliding the recorded audio earlier so that it's laid down where it would been if there were no latency at all. Without that, any recorded audio is going to sound terribly late on playback.
 
To really get record latency compensation dialed in, you should check the actual round-trip time using the free CEntrance ASIO latency tester (Google it), and enter the difference between what it reports and what SONAR reports for Total Round Trip Latency (RTL) as the Manual Offset in samples. i.e. Manual Offset = CEntrance-Measured RTL - SONAR-Reported RTL. Usually this will be a positive number of 10-50 samples - not hugely important or noticeble most of the time, but nice to know it's exactly right.

Turn off your WiFi (switch or key combo) maybe. Usually problematic to a degree.
 

brundlefly

mettelus
 2) you do not have "Use ASIO Reported Latency" checked.

Good catch. That should definitely be enabled, especially when running a large ASIO buffer. It won't affect anything that happens in real time, but it ensures that all of the input latency is compensated after the fact by sliding the recorded audio earlier so that it's laid down where it would been if there were no latency at all. Without that, any recorded audio is going to sound terribly late on playback.
 
To really get record latency compensation dialed in, you should check the actual round-trip time using the free CEntrance ASIO latency tester (Google it), and enter the difference between what it reports and what SONAR reports for Total Round Trip Latency (RTL) as the Manual Offset in samples. i.e. Manual Offset = CEntrance-Measured RTL - SONAR-Reported RTL. Usually this will be a positive number of 10-50 samples - not hugely important or noticeble most of the time, but nice to know it's exactly right.

On the test the result was: 832 samples / 17.33 ms
Sonar reported 726  latency a difference of 106, quite a bit more than 10-50. Is that a problem?

Not really a problem, but definitely on the high side. Usually the delta is mostly due to unreported D/A/D converter latency which is on the order of .5ms each way. Added hardware buffering for USB interfaces can add to that, but a well-written driver should at least estimate the extra latency, and report that to the host. But it doesn't really matter what the number is. So long as it's consistent at all buffer sizes - as it should be - you can just enter that 106-sample difference as the Manual Offset and everything will be good.
 
 

I was having a similar issue and in another thread I read a suggestion to delete or rename the Sonar "AUD.INI" file.  I renamed mine to oldAud.ini.  When you start Sonar again, it will create a new one.  This made a huge improvement on my machine, although I don't really know why.
 
lol
 
You find the file under Drive:>Users/Username/App Data/ Roaming/Cakewalk/Sonar Platinum
 
Worth a try.  Good luck.

What is the path for the "AUD.INI" file?

As Tony mentioned, it defaults to "C:\Users\[Your Username]\AppData\Roaming\Cakewalk\SONAR Platinum"
 
Rather than blindly deleting that file, it is better to rename it to something else (AUD.bak or such) just in case you need to put it back. There have been a few instances where people reported the new one was worse, but is rare.

Have you installed any new software recently?
 
Is the project bigger than usual? 4GB is arguably too little memory for a 64bit system.
 
Have you looked in Task Manager to see if there are other processes that are competing for CPU use?

Agree completely with Kylotan on the amount of memory you have. 4GB is woefully inadequate for a modern-day DAW. Even 8GB would be just ok. 
 
I would disable any network/wifi connection and A/V temporarily to check, and renaming the AUD.INI
and letting the system generate a new one as has been mentioned.
 
Good luck!