X3eP midi latency vs Microhost

I searched but could not find anything on this. I know that X3 is a massive system compared to any of the microhosts for Cake synths. That being said, should there be a drastic difference between the two when it comes to pressing a key on my controller and hearing a note sound? MicroHost = instantaneous, X3 = unplayable delay. 
 
My xface is a Line6 UX2, I have a reasonably fast machine.
 
Thanks for your thoughts.
 
 

The Line 6 does not seem to have midi ports, so that implies your using a USB midi controller. Therefore the drivers of the LIne 6 should not be a factor, The drivers that come with your keyboard will be,
But this sounds like a classic case of midi delay caused by having certain plug in effects running, for my system I have to by pass any of the LP64 plug ins or I'll get delay. 

@emwhy - asio4all, 512
@johnnyV - No plugs at all, brand new project, totally clean.
@dubdisciple - everything the same between MicroHost and X3.
 
Just seems logical to me that X3 could have a path for processing time sensitive midi that would be closer to the MicroHost. As it is I have to write in the MicroHost and transcribe in the PRV. 
I've gone through the disable HD Audio Tip/thread from Craig. No joy. I'm at 32ms, 1400+ samples

Ok, strange things be afoot.
 
Opened X3... unplayable at normal poor latencies. Closed it and opened MicroHost (MH). Lovely, snappy as all get out.
 
Somthing said to reopen X3 without closing MH. Now, it too is beautiful! And when I go to Pref->Driver Settings it tells me my funky 32ms 1400+ has changed to 11.6msec at 512samps.???!!!???
 
i'm afraid to turn the machine off now...
 
But wait, I figure out eventually that I wasn't hearing X3, I was still hearing MH. X3 wont' make any sounds. Oh, well. Driver sharing is on but having the MH open messes up X3. But those latency numbers show me it can be done. Still don't understand the difference....
 

ASIO4ALL is not the best option, but still I have not seen a card which can not do 192 samples with it under SONAR (on computers which you will not consider to use even for reading e-mails).
Still it is better to get the original Line6 ASIO driver first.
 
How do you come to 512? Do you have "cracks" with lower settings?
Please wait a bit after SONAR startup till tests. Especially in case you have "every time VST scan" enabled.
 
1) May be stupid advise, but I still have to mention that: check that you really using ASIO driver model in SONAR.
2) Check that you use the same settings, the frequency and the resolution (44.1/48/96, 16/24).
3) Also check that all other audio devices are disabled in SONAR.

If you are using the UX2 as your only audio interface why are you using ASIO4ALL rather than the Line6 ASIO driver for that interface?

ASIO4ALL is not a "real" ASIO driver but a software hack which tries to get the Windows driver to behave as an ASIO one. ASIO4ALL can be useful if you have to use the built-in soundcard on the PC motherboard or if for some reason you absolutely have to use more than one interface at a time, but if a manufacturer's ASIO driver exists it will (almost) always give better results than ASIO4ALL, be better behaved and more stable. Manufacturer drivers are also usually much easier to configure. For some reason some people seem to be under the impression that because ASIO4ALL can be persuaded to work (after a fashion) with almost anything it is therefore the best driver for almost anything. This is not so. It is better than the Windows driver is you have a realtek or similar chip in the PC and no other interface, but that's about it.

The microhosts and Sonar have seperate audio driver settings, but what one can manage the other usually can as well, or very near it. 512 samples is not a particularly low buffer either as it happens. At 44.1 or 48KHz sample rates you'll still be getting quite a lot of round-trip audio latency.

Try uninstalling ASIO4ALL amd downloading and installing the latest driver form Line 6's website. Install it then Sonar's preferences should let you select it as hour audio driver. Buffer settings will be enabled either through Sonar's preferences or the driver's own interface or both, depending on how it's been coded.

@John - Rapture, DimPro, Z3ta2.
 
So I tried the Line6 drivers and while the gave me worse round trip latency numbers (1963 samples vs 1400+), they remove the midi delay so I can work. 
 
I still would like to know why the MicroHost makes X3 have such lower Latency numbers and why X3 can't reproduce these normally. 

My RME works at exactly the same sample buffer in X3 and the Cakewalk microhosts with no problems. That's a 42 sample buffer at CD quality or 24/48. 4.8ms round trip.

OK, RME come in at a somewhat higher price bracket than Line 6, but my Edirol/Cakewalk UA-101 runs fine at 112 samples with 8 inputs and 4 outputs active. The sample buffer size reported by many interfaces can't be trusted by the way because many contain hidden "safety buffers" that the driver does not report properly. ASIO4ALL isn't exactly reliable as to actual buffer size either in my experience of it.

The buffer sizes you report seem enormous, what happens with smaller buffers? Dropouts?

Have you checked the PC for PCI bus latency issues? PCI bus latency is the intervals taken by the PC hardware to catch up with queued tasks and if it's too large it can cause all kinds of problems with DAWs. Might I suggest you download latency check monitor (from http://www.thesycon.de/deu/latency_check.shtml. It's free - note it doesn't work on Win8 but you say you're running Win7 so should be OK). Run it for a while and see what it comes up with.

A thought's occured to me. You are only using the one audio interface at a time - the UX2?

Latency comes from two sources:

• Your audio interface
• Latent Plugins (typical examples are "mastering", "linear phase", or "convolution")

You've got a choice of buffer sizes for the audio interface.
Smaller ASIO buffer sizes result in smaller latency.
 
All major DAW applications have automatic Plugin Delay Compensation.
Thus, if a latent plugin is added *anywhere* in the project, ALL other audio is delayed by an equal amount to maintain sample-accurate sync.
 
You may be able to run heavier loads (glitch-free) in one host application vs. another...
But... (unless the host application is using an additional processing buffer) playback latency should be identical.

Thanks Jim... it may just be a reporting issue. 
 
ggg