"Cakewalk is making a fix for that delayed arm issue from what I understand."
 
Source or did you just make this up?
 
As I said this is a absolute classic drivers issue, and it's not the first time bugged drivers have done this and it probably will not be the last.
 
OK want evidence? Do you notice any similarities here which turned out to be buggy drivers?
Notice I wasn't initially convinced either... Not until post #68 (well in fact later than that even). So if I took this long to convince I suppose you will never be convinced ;)
http://forum.cakewalk.com/SOLVED-FOCUSRITE-BUG-Record-arm-buttons-are-slow-to-respond-m2391347.aspx
 
That is my compelling evidence from just over a couple of years ago, the comparison here is uncanny, please supply yours...! :)
Ask yourself why my drivers work and yours don't ;)... and once upon a time your drivers may have worked and mine didn't.... and the symptoms here are almost identical.
 
DISCLAIMER - I still maintain an open mind as no official statement has been made from either party (we are just going on hearsay), all I can do is present what I perceive to be a smoking gun drivers issue.. Until Cake or RME officially confirms this anything anybody says (inc me) should be taken with a pinch of salt.

CakeAlexS
"Cakewalk is making a fix for that delayed arm issue from what I understand."
 
Source or did you just make this up?
 
As I said this is a absolute classic drivers issue, and it's not the first time bugged drivers have done this and it probably will not be the last.
 
OK want evidence? Do you notice any similarities here which turned out to be buggy drivers?
Notice I wasn't initially convinced either... Not until post #68 (well in fact later than that even). So if I took this long to convince I suppose you will never be convinced ;)
http://forum.cakewalk.com/SOLVED-FOCUSRITE-BUG-Record-arm-buttons-are-slow-to-respond-m2391347.aspx
 
That is my compelling evidence from just over a couple of years ago, the comparison here is uncanny, please supply yours...! :)
Ask yourself why my drivers work and yours don't ;)... and once upon a time your drivers may have worked and mine didn't.... and the symptoms here are almost identical.
 
DISCLAIMER - I still maintain an open mind as no official statement has been made from either party (we are just going on hearsay), all I can do is present what I perceive to be a smoking gun drivers issue.. Until Cake or RME officially confirms this anything anybody says (inc me) should be taken with a pinch of salt.

look at the RME forum and you will see.

Anyway, here is the forum post:
http://www.rme-audio.de/forum/viewtopic.php?id=19003
 

I should also note that the driver switching workaround mentioned above cures both the slow arming and the glitchy audio on my system. So despite RME's statement that the fix CW developed (and hopefully present in x3e) is only for slow arming and should not affect any performance issues, I hold out hope that the fix will address both.

Sorry Neighbod but I'm not telling people how to post and I have a right to an opinion as do you but you seem to be telling me what to do. BTW I should have been quoted as well if you were going to quote a response, I said "Source or did you just make this up?". I did not say "You are making things up", and it turns out in the end there (eventually) was a source. You are all trying to make it appear worse than it actually was by turning my question into some sort of statement. I also apologised for being abrupt (which I was).
 
> Thank you Matthias, I was confirming because we have SONAR fanboys that have trouble admitting SONAR has flaws.
 
Calling me a fanboy is another forum Conley is sort of weird to be honest (Really???? I have trouble admitting Sonar has flaws? There's plenty of things you can say about me but that doesn't hold any ground whatsoever). What I do have is trouble seeing an issue without the full evidence to back it up, I have a rather scientific approach here which may seem a little over the top to you but sometimes you do need it in a thread that seems to make a lot of assumptions to maintain balance. I'm sorry my immediate apology wasn't good enough for you and I shall apologise again.... I apologise. Now...
 
> Please correct me if I am wrong. The fix, coded by cakewalk, was to address the long time it took for tracks to actually arm and has not much to do with the performance issue SONAR users are having with SONAR X3 and the RME interfaces.
 
This seems to imply that other users who are not using RME interfaces are having delay issues when arming and RME seems to be nodding along to this statement. But I haven't seen any recent evidence of this, is there any sources to show this as an issue away from RME interfaces?
 
Again DISCLAIMER (as I've said all along), these are of course just my opinions, not Cake's or RME's. I will be happy to be proven wrong if indeed that is the case, I do not see this as a point scoring exercise about who is right or wrong, chances are I will fall flat on my face, I just want to get down to the facts here.
 
Could Cakewalk please confirm that there will be a bugfix? Like said if this is indeed true an issue with ASIO/transport is an extremely serious issue I would have thought (although most of us don't see the symptoms it seems). At least we all agree we want to hear from Cake.
 
Thanks...

This is mainly fixed in X3e.  The delay in arming tracks is fixed, as well as the pops and clicks I got when arming and disarming.  If others can confirm I will mark this as "fixed."
 
The pops and clicks I get at other times (e.g., closing the preferences dialog) are still there until I switch driver mode as I noted earlier in this thread.  Given few others have had this latter issue, I expect it is related to some as-yet-unknown hardware or software issue in my DAW.  Fortunately with the effective work around I don't feel the need to figure it out.
 
 

Conley.

So I admit it, you were right and I was wrong, see I can do it :)
Still I had disclaimers littered everywhere so you can't sue me ;)

Anyway for your enjoyment:
http://youtu.be/T4Nh7E9BMdM

:)
 

UPDATE - I may have to withdraw that apology as I notice you have new drivers and firmware!!!:
http://www.rme-audio.de/en_downloads.php?page=content/downloads/en_downloads_driver&subpage=content/downloads/en_downloads_driver_fireface
 

I may have to reverse my previous apology because I notice there are new drivers and firmware out with several bugfixes 
 
@Neirbod, check the latest drivers for fireface here:
 
http://www.rme-audio.de/en_downloads.php?page=content/downloads/en_downloads_driver&subpage=content/downloads/en_downloads_driver_fireface
 
Under readme.txt
 
"Improved Undo: Loading a Workspace after editing Snapshots removed the last edits from the undo buffer"
 
Cheers...

With X3d and now x3e I've had a problem when I first open a project after the update.

I get clicks and pops as the audio engine engages and crackles galore, BUT the audio engine never actually runs. All the track and bus meters move as the project runs. The Master bus is pegged full with no further movement but the audio is never audible.

Quite by accident I made an accidental move on the screen which I undid with ctrl +z, When I closed the project I was asked to save it which I did.

On opening the same project everything worked. The project was created in X2a.

When I installed x3e this evening I had exactly the same experience on opening any project. When I opened the same project I had earlier got to run smoothly in x3d it too started to behave as per my earlier experience with X3d, so I made a small screen change and then using ctrl +z undid that and then saved. Again everything worked after closing then reopening Sonar. No matter which projects I opened they all worked OK. It's the weirdest thing but only in x3d & e as I detailed.

I didn't report the problem as it was fixed conclusively after the one fix and didn't come back until this update and now again is fixed.