neirbod
There was some setting in Sonar related to the "arm tracks while transport is running" option that apparently could be tweaked to help address this.

Ah.. now it's making more sense!
 
"allow arm change during playback/record" is a common workaround for dodgy drivers.
 
Years ago older versions of Focrusrite Mix Control had some nasty bugs such as lag when pressing SOLO buttons, and that was the workaround until Focusrite made the fix and it all started working.
 
OK you will be expecting a fix for RME, at least they are working on it.
 
RME users experiencing issues should try the workaround:
Preferences -> Project -> Record -> Allow arm changes  during playback/record = Untick.
 
Cheers...

CakeAlexS

neirbod
There was some setting in Sonar related to the "arm tracks while transport is running" option that apparently could be tweaked to help address this.

Ah.. now it's making more sense!
 
"allow arm change during playback/record" is a common workaround for dodgy drivers.
 
Years ago older versions of Focrusrite Mix Control had some nasty bugs such as lag when pressing SOLO buttons, and that was the workaround until Focusrite made the fix and it all started working.
 
OK you will be expecting a fix for RME, at least they are working on it.
 
RME users experiencing issues should try the workaround:
Preferences -> Porject -> Record -> Allow arm changes  during playback/record = Untick.
 
Cheers...

This is not likely an issue of dodgy drivers as it is a non standard DAW ASIO practice SONAR uses. That is what I read. At least both parties have come together to figure it out.

When a fix comes, from Cakewalk and/or RME, I will definitely be on it.
Thanks for the info on the untick, but mine was already unticked...

> This is not likely an issue of dodgy drivers as it is a non standard DAW ASIO practice SONAR uses.
 
Well RME is seemingly the only interface company having issues right now, and like I say the EXACT problem happened with Focusrite which they fixed. RME pointing to "allow arm change during playback/record" is a total smoking gun. Did RME test their drivers with Cakewalk? Obviously not until now. Go figure! :)
 
BTW ASIO is protocol, there really isn't a "non standard" way of consuming it, it either works or it doesn't And Cakewalk supplies an off button as a workaround for those drivers that do not support Cakewalk (or are buggy) so they've covered that scenario as well.

Expect a fix from RME and not from Cakewalk, and when RME releases the fix and it works without any change in Cake's code, then expect everybody to somehow believe it's still Cake's fault (as is the norm) even though what they do is actually to help the third parties to fix their own issues when consuming Cake's hook in points :)
 
Cheers...!

If Cakewalk is the ONLY DAW working this way, according to what I read above, that to me either states that CW is trying to set a new standard or they are not following what has already been established by other DAW vendors that work well with RME.  
 
Either way, I would like this fixed.

BTW all DAW vendors will do things slightly differently, this "standard" sounds like something mythological, and a protocol is a protocol that either works or it doesn't. It may well be that Cake is doing something better than other DAWs (and like I said, they supply an off button!). This really does sound like a flimsy excuse from RME somehow trying to explain why their hardware is not working correctly with Cakewalk, esp when they give this workaround that Cake provides. If they'd given any other workaround I would have hesitated with my comments.

Focusrite I remember owned up to the issue pretty much straight away, and said they were working on a fix (admitted their fault) which they took about 3 months to fix at the time. As I say again, RME is the ONLY company experiencing this issue, I feel they are introducing smoke and mirrors at this point if this is indeed what they actually said (we can't really confirm as we have no direct quote), and I look forward to them making their drivers compatible with Cakewalk in the new future.

LOL

Guitarmech111
LOL

 
ABOVE THIS IS THE LAST WORD!!!! :) :) :)
Have a great week Conley...

CakeAlexSThis really does sound like a flimsy excuse from RME somehow trying to explain why their hardware is not working correctly with Cakewalk, esp when they give this workaround that Cake provides. If they'd given any other workaround I would have hesitated with my comments....I feel they are introducing smoke and mirrors at this point 

 
I am sorry I posted anything about this.  RME excels at customer service and driver support.  I don't like seeing anyone take a small amount of information (especially when I am the one who provided it!) and start making dramatic statements calling into question a good company's well-deserved reputation.  On more than one occasion over the years, I have seen them respond to a troubleshooting inquiry with a "Yep, our fault.  Update coming soon" followed by a fix usually within days.  I would expect the same this time if it were simply a dodgy driver.  
 
For the record, my UFX works great with 8.5.  
 
Guitarmech - it is not the EQ+D for record option.  It is the bandwidth dropdown box above it.
 

Well as I said, "we can't really confirm as we have no direct quote" however recommending the disabling allow arm change during playback/record clearly points to the actual issue with the driver (and the fact that other companies drivers are working fine). Plus they clearly never tested the driver with Sonar 3.
 
Every company has had a dodgy driver one time or another, even Focurite, there's no shame in that. It's how they play it out and how transparent about it is what makes a companies reputation IMHO. I have had not seen any official response so I shall take everything I hear with a pinch of salt until we do.

Cheers...
 
(Edited as I wrote "Cakewalk" instead of "Sonar").

I have the 1.043 driver and I do not see any bandwidth box. My hardware revision is 353 with Win7.