Following the MILAR instructions, I put a UAD LA-2A, PSP Vintage Warmer, Magneto Tape emulator, and a Waves SSL Buss Compressor as a chain in my Final mix Buss.  Even with my new Quadcore drivers replacing my EMU 1820m, I coul not have the FX Bin on when input monitoring a vocal or guitar recording because of the delay; I had to bypass the bin to eliminate the delay.  I tried to isolate the hungry plug-in, and found that the PSP warmer seemed to introduce the most latency.

However, I eliminated these plugin from the Master Buss and instead loaded the PC Master buss preset with the LA-2A and SSL emulations.  I then loaded the PSP warmer and Tape emulator in the PC Fx bin.  With everything on, there is no distracting delay on the input monitoring.  Why/how does the PC which is doing the same thing as the FX Bin in the first set up able to have the decreased latency?
In the first set up, the LA-2A is on its own DSP card and all the others were VST plugins.  I am naïve to plugin latency, but I am surprised that the warmer and tape plugins cause delay when is series with the VST plugins and do not, apparently, when in series with the PC emulations.  What do you think??

Hi Larry,

Latency comes from two potential sources:

• Audio interface
• Latent plugins

In your first example, you're using latent plugins.  (Plugins that use additional buffers)
Mastering type plugins often use "look ahead" type processing... which requires more buffering (latency).

In the second example, you're not using latent plugins.  


UAD plugins sound great, but you're dealing with additional latency because audio has to be routed to/from the DSP.

Hey Jim,

I've seen your posts in other areas and I can tell you have a lot of experience in this matter.  I totally understand the hardware (audio interface) side of things.  I've been in the IT business for 40 years and the way I troubleshoot is "Process of Elimination".  I'm tired of throwing $$ into hardware only to be disappointed.  I also get tired of the "finger pointing" on where the problem lies.  For the last time, I've purchased a PreSonus 1818VSL Audio Interface.  They have their own software (Visual Studio Live) and there is a 3rd party iPad app called "Auria" from Wavemachine labs.  So I'm going to try running both of these apps and if they outperform X2, then it is clearly an X2 issue and Cakewalk needs to step up to the plate and fix their product. Just so you know, I'm not using any plugins that aren't integrated into X2 or developed by Cakewalk. So, when you mention "latent plugins", I'm assuming you're talking "3rd Party"?  If we are talking "BREVERB, R-MIX, Console Emulator, or any of the other Cakewalk developed plugins, then I have a real problem with that. Don't give me all the "Marketing Hype" to sell me X2 when it comes with "latent riddled" plugins.  Feel me?


I've been using Cakewalk products for years even before the branding SONAR came to market. I've removed any potential bottleneck from my DAW by disabling unnecessary apps (i.e. A/V, Disk Defragmentation software, etc) and even disabled CPU core parking. My quest for the "Holy Grail" is to have a system I can use in the studio as well as on the road (live gigs), without the latency. If I come the the conclusion that an iPad (of all things) can work with my PreSonus 1818VSL or their own VSL software, I'm going to shelve X2 and be done with it. Software manufacturers (that includes Microsoft), keep developing products that require more resources ("FAT" software), versus other manufacturers that develop "resource friendly" products.  My vote is with the latter.

SONAR X2 doesn't ship with arbitrary "latent" plugins. The plugins that induce delay are perfect space, R-MIX, the console emulation, and some of the compressors. These do so for a reason - they require look ahead buffers for processing. 

Troubleshooting delay compensation related latency is very simple in SONAR. Click the ADC button on the control bar in the transport section and it will disable delay compensation. If you have no latency now,  it means that the delay was caused by a plugin in the circuit. You can now use a process of elimination by removing the plugins/modules one by one.

If you still have delay it could be for a few reasons:

- You are using an audio buffer size that is too large for your audio interface. Check the driver mode in ASIO the buffer size is exactly what you set it to in the ASIO control panel. In WDM it is what you set on the latency slider multiplied by the the number of buffers setting. 

- Latency could also by caused by the driver - check your drivers control panel for related settings.

Noel,

I will go through these steps again and see if I missed anything.  I've set the ASIO buffer size to match the ASIO control panel and that makes it even worse.  Believe it or not, setting the ASIO buffer size to 2048 (maximum) has achieved the best results.  According to CW support, I need to get my RT below 10ms.  My current audio interface (TASCAM US-1800) @ "lowest latency" can't achieve less than 15ms.  FYI, I'm using one of CW sample projects to test with "Jodi Good  - Where Did We Go Wrong".  My issue is really about SONARPDR.exe locking up.  When I get latency under 10ms as I did with Focusrite Scarlett 18i6 (7.7ms), the process would hang.  The memory footprint for SONARPDR.exe starts at about 700-800 MB.  Increasing the ASIO buffer size to max (most stable), increased the memory footprint for SONARPDR.exe to 1.4 MB.  Not a big issue considering I have 16GB.  I will play around with the PDC a bit more (you mean't PDC not ADC, right?) and see what I come up with.  I have to give X2 the worst case scenario and fully regression test.  So, are the look ahead buffers emptying and not back filling quick enough and crashing X2 (buffer under run)? Seems to me this is the issue.  When the plugin process attempts to grab data from the "look ahead buffers" and there is no data there (empty), the system crashes.  My best layman's analogy here is that a 5 gallon bucket filled with water at the same drain demand, will take longer to empty than a 1 gallon bucket.  That's why increasing the ASIO buffer size to 2048 has given me the best result.  When I decrease the latency, I increase the demand and the buffer empties quicker.  Does my assessment sound correct?

I hate to say it but from your description if switching to a lower latency with just the sample project is causing a lockup, its looks like you have some device driver instability or the driver itself is deadlocking somehow.

Even with onboard audio I am able to set the latency to about 6 msec and have no lockups whatsoever. Its highly unlikely that the cause of the hang is within SONAR, if not pretty much every user running at low latency would see this. A latent deadlock in the code WILL happen to everyone at some point when exercised enough.  

To explain the latency scenario in more technical terms, all that happens from SONAR's point of view when the buffer size is smaller is that driver callbacks are much more frequent and thereby the CPU load is higher. There is of course a greater possibility of a dropout but it shouldn't make the app more unstable unless we had a deadlock scenario. That is more or less ruled out since there are thousands of users running X2 today at very low latencies with no problems. That leaves the driver and some external factors as possibilities to investigate. 

To narrow it down further experiment with other driver modes with your device - WDM for example and see if the same issue persists. You could also try your onboard audio as a test to narrow down the problem scenario. Unless you are running sub 10 msec buffer sizes you WILL have audible buffer induced latency. 
If you want us to investigate the source of the hang you will have to send us a minidump file that can capture the state at the time of the hang. If you don't have the tools to do that, contact support and they will send you a utility to capture the hang dump. The stack at the time of the hang could show what is causing your system to lock up.


PS:
You are running the quickfix right?
 
ADC == automatic delay compensation. The button on the toolbar disables SONAR's automatic delay compensation mechanism which can be caused by plugins or external inserts. 
PDC = plugin delay compensation.

Gio

I have an 1818VSL as well trying to run Sonar on a beast of a machine (SSD hard drives, 6 core i7 64Gb Ram - Fully tuned windows settings for Audio) and I have terrible trouble with Latency that I never got until switching from an RME Fireface to the 1818VSL.

If you look at presonus forums there are lots of people having trouble on there with the 1818VSL and Sonar.  The two simply don't seem to like each other, personally I am not a fan of the 1818VSL at all and think that is where the problem lie as I never had a problem with Sonar using other interfaces.

Is anyone else out there using the presonus 1818VSL that can prove me wrong as I hate wasting money on hardware?

Where is the ADC Button? I don't see it on the control bar transport section. I have the PDC on the mix module but no ADC.