Arming tracks and changing preferences is DELAYED with some RME products

Although RME products are highly reputable, many users (myself included) encountered this when using the Fireface UC and UFX:
When one presses the arm button there's approx. 1 (one) second until it turns red and armed. Disarming it it's also not instant but it seems to take less time than arming.

What's more, any action that's being done in the Preferences window, takes minimum 2 seconds before the new settings are memorized.

For example: enabling/disabling one of the Fireface UC's input/output drivers takes 6 (six!!!) seconds after clicking the "Apply" or "OK" buttons for the new settings to be memorized.

On the other hand, if one opens the Preferences window and then clicks "Cancel", then the window disappears instantly.

Has anyone here encountered this? Is this a Sonar or an RME issue? Is this any different in X2?

Here is an older thread on the RME forum that suggests the issue is in Sonar itself:
http://www.rme-audio.de/f../viewtopic.php?id=10079

The issue is *not* Sonar itself.

ie:  If you arm a track when running a FastTrack Ultra 8R or the Fireface series, you'll experience some delay.
If you arm a track running a MOTU Firewire unit or the newer Presonus VSL series, the response is immediate.


The response time is almost alarmingly immediate when changing audio preferences running a VSL series audio interface.  The fastest I've seen with any audio interface.

I have a slight delay with RME and my M-Audio FTU (both ASIO). I've always assumed it was the drivers doing a 'handshake' so I've never thought of it as an issue...an annoyance true, but not an issue.

Somewhat akin to a 'gapless audio engine' or lack thereof. ;-)

Regards,

Yeah, but I was hoping it would be resolved one day... True, not an issue but an annoyance. And no one seems to know what's causing it...

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

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...

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 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.

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.

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.

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).

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

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

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 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.