I can confirm that none of the settings mentioned above have any affect on the "record-arm delay".

When using small ASIO buffer sizes, you can start the transport (play)... and arm/disarm a track (on-the-fly) and the audio engine will drop-out. 
If the track is already armed, punch-in/out recording works perfectly fine (instantly).

I reported this at the lauch of X1 but no answer since.

RME gear + SONAR is running 5000 hours per year in my setup. During the past 8 years I have ran SONAR with RME >40,000 hours. One could say I have gained experience...
 
In the "good old days" 32 bit XP + 2 x Fireface 800 + SONARs up to ver 7 worked together perfectly. Problems began after I upgraded to 64 bit Win7 and 64 bit X1. Slow arming when playnback is off (but instant when it's on), audio engine freezing even in simple projects and SONAR losing connection with ASIO driver (though this does not happen in X2 anymore).
 
In SONAR I have tried to tweak all possible parameters one could imagine. No cure. Then I suspected it was a hardware flaw. I sold both FF800 units and bought RME UFX. Identical behavior. I tried several Firewire cables. I have tried 6-8 different Firewire interfaces - with or without TI chipset. No difference; mobo interface works as well as TI based PCIe cards. I have checked DPC latency, verified system with Latency checker, had a long converstation with Cakewalk Support (no solution), even longer conversation with RME support (no solution either). I have tried to disable virtually every possible background process and tweaked BIOS settings to death. I have made extensive memory tests. I have replaced power supply twice and measured voltages, DC ripple etc. I have verified that house AC is clean and healthy. System temperature is very low. CPU fan is huge. No overclocking (i7-950 running @ 3.04 GHz).  Drivers are up to date. I replaced hard disks and SSDs (O/S is in SSD, most programs in a RAID volume and projects & data in five 1-3 TB drives).  Recently I replaced video card as well. No change.
 
Vegas Pro 12, Sound Forge and Melodyne don't have any problems with my hardware. They all work great with RME ASIO driver and I don't remember a single audio engine related crash in these programs. Also Media Player and Winamp always work perfectly.
 
Probably I forgot to mention something but probably I have tried it, too...:-) I build a new PC for SONAR in few months. If problems still go on, I'm running out of ideas how to improve stability. Last part to replace is motherboard (Asus P6T).
 
 
<GUESSING>I am almost sure that freezing program code is not in SONAR. It looks like SONAR sends a query or command to ASIO driver but does not get response. After timeout SONAR becomes responsive again but audio engine is lost.  Maybe other programs talk with ASIO driver in a slight different way.  At home I use SONAR with Cakewalk USB audio interface and it works great. </GUESSING>
 
-Panu

Wow, Panu, what an exhaustive effort! Thanks for this great post! I'm just going to sit back and wait for a new driver. My bet is that there is some minor feature which RME did not include in its driver which is being called, as you said, by Sonar. If RME adds it, then the problem will disappear. I'm also betting the Sonar developers know what it is and might tell RME, just to be friendly.

I agree with Jim R.. this has been happening for awhile.  I am using an OCTa Capture and have the same delays when arming or de-arming recording on AUDIO tracks.

I have not idea what causes this.

Jim

I noticed today that my Line6 GX has the same problem. I wonder if the problem was introduced when Sonar started allowing users to arm tracks while recording... ? Do the DAWs that don't have the problem allow this? Did the start of the problem align with this feature?

PopStarWannabe


thank you for this thread and your testing

now I have the feeling to be less alone...
I am not sure both cakewalk and rme care about this "issue"

I bought x1 but did not like it, so I will not upgrade to x2
I will keep 8.5 but I bought an alternative daw

I'd go as far as claiming that the length of delay (between pushing ARM on the surface and actually arming the track in Sonar) is dependent on Sonar screen settings. It is definitely worse once you enable 'Auto Track Zoom'; in this case the delay also becomes very noticable with the MUTE buttons.

I tried to post an enquiry here (http://forum.cakewalk.com/fb.ashx?m=2745317) but got no replies

I noticed delays in arming tracks for recording when I upgraded my interface to an RME UFX - coincidentally I was also going from 8.5.3 to X1 at the time, which was a bit unstable in general.  I reported it to both Cakewalk and RME. 

Cakewalk said it was a driver issue with the RME interface.  RME tech support said they were aware of the issue and it would be resolved in a future driver update.  Subsequent RME drivers did decrease delay when arming tracks for recording in X1 significantly.

I have the latest RME UFX driver & still experience some delay when arming tracks - it's not even close to the instantaneous response I got for years under all versions of Sonar and with several different previous (non RME) interfaces, however it's not that big a deal for me now that the delay is less, so I haven't continued to push the issue.

Message from the boss of RME:

"Thanks for the post in the Cakewalk forum, nice info now there. I wonder if Sonar resets or stops/starts the ASIO driver each time a record button is armed. All the other programs mentioned start ASIO when you start the program and never stop it. Record arming and record on/off is virtual, so to say. If Sonar does that differently then the delay can not be fixed from our side, as it is based on the basic design of the USB and FireWire driver. The PCI/PCIe drivers will most probably not show such a behaviour (PCI/PCIe is still the fastest you can get...in any way...)."

Post is located here: http://www.rme-audio.de/forum/viewtopic.php?pid=81048#p81048