i tried ubuntu a couple of years ago, ok for office & internet but not daw or games

Sanderxpander , I made the switch soon after I picked up X3e P.E.  ….lets just say it has been very educational ...
I'm not dealing w any config issues over on that end and that is nice , yet I can say they both have their strengths and weaknesses  
 
Kenny

keyzs
The reason for this conclusion is that when ASIO first came out, it was not without issues, however it was the beginning of a dedicated audio streaming protocol that attempts to bypass the OS audio kernels, hence reducing full duplex audio delays. Although technology has improved tremendously since the first ASIO codec was released, the new and or old codes were never properly addressed to solve issues. Then came WASPI and WDM etc... These are just codes over codes which cover over even more codes.... Marketing has always dubbed these as new technologies... unfortunately not. Thats why there are still traces of legacy code to begin with (post #61)

 
Just to clarify some inaccuracy here. ASIO does *not* bypass the OS kernel. ASIO is a user mode layer (exactly like a plugin dll in that respect) that sits on top of the OS kernel. In fact on Windows every driver vendor who writes an ASIO driver must additionally write a kernel mode driver for the actual communication with the audio interface. What the ASIO dll does is communicate with the kernel mode driver using lower level calls, typically IOCTL's. This mechanism bypasses the higher level windows API's and the multimedia stack, like MME, WASAPI etc, so it has some advantages since those layers introduce buffering.  Kernel streaming, that Cakewalk was the first to implement support for, follows a very similar approach. It bypasses the high level multimedia stack and communicates with the kernel mode drivers directly via the KS API that Microsoft published a long time ago.
 
All drivers on the system share the same hardware and low level stack so unfortunately its possible for another inefficient driver to affect performance of another. There is no way around that in the present Windows architecture. Microsoft made some progress using MMCSS but its not a foolproof solution.

Noel Borthwick [Cakewalk]

keyzs
The reason for this conclusion is that when ASIO first came out, it was not without issues, however it was the beginning of a dedicated audio streaming protocol that attempts to bypass the OS audio kernels, hence reducing full duplex audio delays. Although technology has improved tremendously since the first ASIO codec was released, the new and or old codes were never properly addressed to solve issues. Then came WASPI and WDM etc... These are just codes over codes which cover over even more codes.... Marketing has always dubbed these as new technologies... unfortunately not. Thats why there are still traces of legacy code to begin with (post #61)

 
Just to clarify some inaccuracy here. ASIO does *not* bypass the OS kernel. ASIO is a user mode layer (exactly like a plugin dll in that respect) that sits on top of the OS kernel. In fact on Windows every driver vendor who writes an ASIO driver must additionally write a kernel mode driver for the actual communication with the audio interface. What the ASIO dll does is communicate with the kernel mode driver using lower level calls, typically IOCTL's. 

Hi Noel, many thanks for your kind thoughts.
 
Yup... ASIO does not bypass the OS kernel; it somehow sits on top of it... just that the OS kernel is kinda like the foundation for building upwards; if its sand or mud we'd all be in shambles  on the other hand if we had a solid foundation to begin with... woohooo!!!
 
i'm sure things will get better at MS and hopefully someday they could implement an installer which will allow the barest of barest minimum to be initially installed so that power users will ultimately make their own choices of what else needs to go in. (Shall we start back at DOS and buildup from there... ) 
 
Glad you mentioned MMCSS... lets hope for now MS can get their "real-time priority" thinngy correct 
 
No worries... we will always make the best of all that is offered...
 
many thanks again... cheers!!!

keyzs
i'm sure things will get better at MS and hopefully someday they could implement an installer which will allow the barest of barest minimum to be initially installed so that power users will ultimately make their own choices of what else needs to go in. (Shall we start back at DOS and buildup from there... ) 

An abstraction layer will always be useful, otherwise Cakewalk will end up writing drivers for all audio interfaces like the good 'ole days.
 
Cheers...

Thanks for the info Anderson, And keyzs for the reg hacks.
 
I have noticed when I turn on in Bios the "on board audio device (Realtec) " with the other HDMI audio running as it does with the ATI video cards, with ASIO in use in Sonar x3e....The mouse problem occurs, with crackling and such when moving it around the screen , No matter the latency number used....Here.
 
I would like to say it could be a IRQ related issue..?..But that is just me being me, as always was, is is still....WINK., or some conflicting switching method used between the devices may be causing the hickups?
 
I feel the Thunderbolt 2 port and firewire adapter, helps me at least have internet with the Zed ASIO sound device in use, which was impossible on just the firewire 400/800 PCIe 1x card port.
 
So progress is happening...
 
I am able to  use the HDMI and ASIO for my ZED and internet, with certain latency settings with no problems so far...using this Thunderbolt port with the firewire adapter...and internet intel on board nic.
 
But I sometimes have to engage the "on board audio" to record the internet into Sonar through my zed....As the HDMI out put on my video Monitor does not seem to work, I have to turn on the "on board sound card" to get the internet audio to pass through it (44.1), and then to my Zed Desk, to record it (what ever setting I want to record it at).
 
So knowing I can turn off the HDMI now...which should clean up the crackling mouse movements when turning on on board audio device is......Great news!...And if it does work, when implemented, I can keep the HDMI off (do not use this device) setting???, and the on board audio left on, with ASIO, perhaps without the issues here?
 
more testing....yip yip
 
Again thanks!
 
Hair is growing back nicely!
 
More Mead is required to celebrate...Cheers!
 
Sir Les
 
 

The key to a rock solid workstation is in the build .
Turning off onboard devices like built in audio even firewire if you dont use it is VIP
as said above it frees up IRQ's and stuff, ive been doing this for years
 
A proper build starts with well selected parts and then build from the bios up..chipset drivers video drivers and in that order are key.
 
Done right X3e will perform 100%....Happy Tracking !

This driver can be disabled in the bios.... Just disable onboard audio....
 
My settings are 512 as latency compensation in Sonar works a treat....

Yep...IRQ's...virtual or not .,...The solution is with this age old problem (not solved)....and we go onwards not pushing for the right solutions...but live with what they offer...to make us pay more for the fixes and or tech support, to not address the real issue!
 
 
So more is not less...and less is not more..?.it has to be solved...and My understanding of IRQs since the beginning of the IBM machine standings are MS handles them improperly at the best of times, causing the conflicts of sharing them when it want to.....which leads to the glitches, freezing states, clicks and pops , crashing and other anomalies, well noted here ...(but workarounds work for now)
 
Perhaps the motherboard IRQ and Cpu capacities  made more of....with E-prom software on chips to run the rodents and keyboard, ports and such, with out addressing the cpu??/ could help resolve more if not all issues, so no one has to turn on or off anything, and all ports or slots have exclusive irq's...and specific cpus to use, would be a blessing?
 
Just a thought since ever was...is, and may come someday....Pray to plug  that idea in?
Wink.

Another update...
 
First, it really does seem to be only the AMD driver that's causing problems. I re-enabled the HD Audio Host Controller but left the AMD driver disabled and had the same level of increased performance. So given Noel's reservations about disabling the HD Audio Host Controller, it seems you can leave it on and still retain the benefits. However, as pointed out earlier, the only way I could actually disable the AMD driver was to disable the HD Audio Host Controller, reboot, disable the AMD Driver, and reboot again. Now it seems part of that process will be to re-enable the HD Audio Host Controller before the last re-boot.
 
Second, again from Noel:
 

All drivers on the system share the same hardware and low level stack so unfortunately it's possible for another inefficient driver to affect performance of another. There is no way around that in the present Windows architecture. Microsoft made some progress using MMCSS but its not a foolproof solution.

 
I think he probably nailed it here, this explains a lot (probably also including why ASIO4ALL can wreak havoc with other, dedicated drivers).
 
Third, I gleaned additional insights from Noel and Keith at Cakewalk (thanks guys!!) to write up an "official" version of this tip that actually answers the question in the thread title. They have graciously offered to look it over and make sure everything is correct. I'll close off my contribution to the thread by including the tweaked version.
 
Let me again emphasize again I have no idea which systems this will help or not help, or to what degree. But even if only 1% of Sonar users have a system that can benefit from this change as much as mine has, that's going to be a very happy 1% of Sonar users. 
 
I'm curious to see what the results are with various nVidia-based setups.