Thanks a lot! Like I said the Fireface is not causing this on others sequencers (I successfully tried Reaper) - so it might be a Sonar issue... But also - indeed - no Windows 8 drivers yet from RME...

Jim Roseberry, I tried my Fireface UC with Reaper and the response is immediate. What version of Sonar do you have?

I'm running Sonar X2... but the delay was the same in X1 (and I believe v8.5).
I'm aware that the delay doesn't happen in Reaper.   
That said, the delay (on record-arm) doesn't happen in Sonar with all audio interfaces.
Got to be something with how the audio interface driver interacts with Sonar.
Maybe Noel could step in and offer some technical details/explanation.
Whatever Presonus is doing with the VSL series, the response time is *fast*.

I have the RME UFX and experience the same delay - I've posted about it historically.  I never had the issue until I upgraded my interface to an RME.  RME driver updates lessened the issue a bit, but there's still about a 1 sec delay (it used to be MUCH longer), so it's tolerable now for me.

 
I tried Cubase 6 AND Reaper. They communicate perfectly with the UC.

If the mountain won't come to Muhammad, then Muhammad must go to the mountain – that means either RME or Cakewalk should fix this. Because I paid hugely 879 Eur for the Fireface UC and at that price it should work perfectly on ANY DAW !

Also Cakewalk pretends to be „industry standard“ and „genius“. They should also try to fix this. Because it looks simply stupid! And because I start to be paranoic and think „if there's a delay at arm recording, then maybe it's also an extra, „hidden“ added latency to the round trip“


I made several experiements:
For some reason, using the WDM/KS driver, the response with the Preferences window is much quicker (almost instant). But the track arming is still sluggish.

There's also this to relate: I also fed the output of the Motherboard's audio card into the speakers along with the signal from Sonar (who uses only the Fireface UC). Whenever Sonar's audio engine is ON, there is a continuous high-frequency buzz coming from the MB's cheap card. When I stop the audio engine (pressing the button in the Transport Module), the buzz stops.

The interesting thing is, whenever I arm an AUDIO track for recording, the buzz stops for a second – to be more exact, for exactly the time the track is being armed (the delay we're talking about). As soon as the track is armed, the buzz resumes. So, there is an interruption of the Audio Engine upon pressing the Arm button.

The buzz also stops for the entire duration the Preferences window is open. As soon as this is closed, it resumes.

I am using RME pcie card and do not have these issues although sometimes I do see a delay the first time I enable a record per session after that it is instant for the duration of the session.

Check the setting you have for the drive in sonar Preferences>Audio>Playback and Recording.

If you have "share drivers with other programs" enabled try turning it off.
Be sure that the "Always open all devices is checked.

The go to Preferences>Audio>Driver Settings and check your playback and recording timing master settings.

It has been suggested that changing those to something you do not use in your projects normally may help odd problems like this. In my case I have the SPDIF device selected since I never use it. 

 Hope this helps.

Tom,

I just tried these steps, and I continue to get the same latency on my UCX.

As I've noted, if you quick group the latency doesn't multiply to do multiple tracks, but that doesn't fix the issue. There is a delay when hitting the record enable button.

G

Ok Sorry. Here is one more thing. Go to Preferences>Audio>configuration file, make sure that the MinimizeDriverStateChanges variable is set for 1 or 3 since you are using asio.

Thanks Tom. I double checked. I was set to 1. I changed the MinimizeDriverStateChanges to 3 just to see. No difference for me on the latency when hitting the record enable.

Tom Riggs, I've tried all your suggestions (except for the one in the Config File). Nothing solved the issue.


Anyway, here's my final and EXACT report on this:

At the time of writing, I'm on Windows 7 x64 with Sonar X1d x64. I carried out these testings in both ASIO and WDM/KS mode.

Following happens:

1) If the state of playback is STOPPED, then pressing the Arm button AND/OR the Input Monitoring button causes a slight (0.7 seconds – I timed it!! :) ) disruption of the Audio Engine. I've described in a post above how I noticed this. However, this disruption is not indicated by the Run/Stop Audio Engine indicator/button from the Transport Module.

After this short lag, arming (enabling monitoring respectively) occurs. Likewise, disarming or turning off monitoring causes the same disruption and time lag.


2) If the state of playback is PLAY, then arming and/or enabling monitoring occurs instantly. No time lag/Audio Engine disruption in this case.

Hope this will help both RME and Cakewalk to remedy the problem.

Pop Star,

if you are meaning to submit this to Cakewalk as a bug report, do so from this link...
http://www.cakewalk.com/support/contact/problemreport.aspx

Do not expect that any developer will ever read this post. I have sometimes included links to threads in the forum when submitting bugs (or what I think are bugs). I have had several bugs accepted and some resolved.

Thanks,

G