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.

What microhost are you using?  I am thinking this is a host for VSTs and VSTis is that true? 
 
 

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

I'm sorry but you are going to have walk me through what you are doing. What you listed are what I call plugin instruments or VSTis and DXis. I was thinking you were using a specialized program to host those plugins for playing them live. I know of a micro host that can load VSTis but its been awhile.
 
The latency you observed is high because you have not set the audio buffer at a low enough level.  

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?

I really appreciate your thoughts and efforts on this. 
 
@John the microhosts I'm speaking of come with X3P. They allow the stand alone playing of those synths.
 
My machine does have latency issues that are beyond the scope of this thread. The real issue is: why the Cakewalk Microhost has such a better reported latency than X3P? Why with the MH running does X3P report stellar latency but then not work properly?
 
We may never know but for now I am able to work with the native line6 drivers which eliminate the midi delay in playing with existing tracks.
 
ggg

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.

Not all applications report actual latency.
 
ie: An ASIO buffer size of 64-samples (44.1k) equals 1.5ms.
Many apps and audio interface control panels list this 1.5ms when set to a 64-sample ASIO buffer size.
But... even when you're just playing soft-synths... dealing with one-way (playback) latency, that doesn't tell the whole story.  The audio interface driver uses a hidden safety-buffer... and you've also got latency from the D/A converter.
So while the ASIO control panel lists 1.5ms, what you're actually experiencing is ~3ms of actual latency.
 
The audio interface's hidden safety-buffer is a major variable.
The best units use a very small hidden safety-buffer with total round-trip latency of ~5ms (input to output).
Other units that use a large hidden safety-buffer can yield total round-trip latency of ~16ms (input to output.
If the audio host application only lists the latency of the ASIO playback buffer, it'll list 1.5ms of latency.
 
Round-trip latency is the sum of the following:

• ASIO input buffer
• ASIO output buffer
• Latency of A/D 
• Latency of D/A
• Latency of the audio interface's hidden safety-buffer

 
Many audio interface manufactures don't like to talk about round-trip latency... and don't mention it.
Even the best units (which yield ~5ms total round-trip latency at a 64-sample ASIO buffer size/44.1k)... it looks better on paper when it's listed as 1.5ms
 
 

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