Here's what Ron Kuper from cakewalk had to say about all this from the Sonar newsgroups...

Peter should know better than to characterize KS as "a hack to solve some
problems." KS is the architecture that all MS kernel mode components have
used to talk to one another since Win2k. Perhaps what Peter should have
(more accurately) said is that KS could be better documented by Microsoft,
with more code samples provided to show how to use it. IOW, our problem was
the latency introduced by KMIXER, the solution was to bypass it by talking
straight to the driver using the same protocol that KMIXER uses -- KS -- but
the solution needs to be better documented.

The fact of the matter is that KS is deeply engrained in the Win2k, ME and
XP operating system. Even the dreaded "kmixer" talks via the KS API. KS is
"pipe" through which audio flows in the Windows O/S kernel.

As far as the relationship of KS to ASIO, ASIO is a layer (an API) on top of
KS. If you are h/w developer begining to write a driver from square 1, and
all you have is the ASIO SDK, you'd be stuck. This is because the ASIO SDK
doesn't address issues such as how to program DMA, how to virtualize IO,
etc, etc. The only thing the ASIO SDK provides is the API for the host app
to use.

If you want to actually write the kernel mode drive, you need the Windows
device driver kit (DDK). The DDK provides the framework for building --
guess what -- a WDM kernel streaming driver.

Later.

doesnt WDM in sonar NOT allow for hardware switching though? isnt all input monitoring in sonar THRU software?

This is kind of dated. It still applies, but is dated.

What was discussed at the Roundtables was trying to get a consitant kernel mode driver interface that would permit the user mode portion of the drivers to be completely side steped.

WDM KS was a promising start to this. WDM Kernel Streaming moves the "API" or user mode layer directly into the application. This can provide more consistency for the app since it controls directly how the app interfaces to the hardware. This has been possible since WinNT first appeared.

All driver level i/o is done through handles to files or devices in an NT kernel based OS. Under WinNT 3.5 a Wave driver was nothing more than a kernel level driver that interfaced to a user mode DLL that provided the "wave" interface that Windows required to expose the driver to the OS. There was some what of a standard interface between the user mode portion and the kernel mode portion, but ther was no requirment on how the driver writer actualy communicated between the user mode portion and the kernel.

The problem with direct communication to the WDM kernel drivers is that Microsoft didn't actually document this interface for app pdevelopers. Through constant pestering by Cakewalk and Sonic Foundry they a white paper and some sample source code to "document" what was required to do this.

It works quite well actually. There are a number of issue that have not been resolved that require some 'back door' hacks to make things work. The round table discussions where an attempt to get all vendors on a common page and develope this method to be a consitent way to communicate with hardware.

However, WDM KS is something Microsoft doesn't like. It is an entry point directly into the kernel. Anything that communicates directly with the kernel is dangerous in that it can cause system level crashes.

What we are still hoping for is a consitent and documented way of doing this. It would provide a direct means to communicate with the drivers and allow hardware vendors to write one driver and not be bothered with the user mode interface.

Still, the user mode interfaces are not a bad thing. They supply consitency for host apps. A well written kernel mode driver can interface to any number of user mode interfaces. In fact, most hardware has a single kernel driver that supplies interfaces to the required WDM kernel mode layer or any number of user mode layers.

ASIO and Wave can be as efficient as the hardware vendor want them to be. They can be multiclient and share the ports with as many apps as they desire. It is entirely up to the lowest level driver that communicates with the hardware. All other APIs or interfaces that a host app uses should be blind to the actual underlying hardware layer.

What can't be efficient is WDM Wave emmulation. Currently there is no means to bypass the OS's KMixer. The Kmixer is a proxy level that controls all paths leading to the hardware. It provides the "best user exeperiance" so that all things will work for the "average" user - which is NOT the user base of applications like ACID, Vegas or SONAR.

Peter

And in English?

Just kidding...

>>And in English?

I agree with one issue that seems to be underlying this all, if it can be fixed within the software and provides a significant or even slight improvement for the end user, THEN THE SOFTWARE SHOULD BE RESOLVED TO MEET THE NEEDS OF THE CONSUMERS, WHO OBVIOSLY PROVIDE Sonic Foundry A MARKETPLACE TO SELL THEIR PRODUCTS, I dunno kinda makes sence to me.

Well stated AudioMAN, I like your mind, IF IT CAN BE FIXED, IT SHOULD BE!!!!

Hmmmm, I wonder if there's somehow the slightest, smallest possibility that AudioMAN Angelic Records are the same person...

Get off these forums. Oh, and get a life.

Ben

is ben rednroll ? :)

this is getting confusing

I was really thinking the same thing Ben. Everytime this "Audioman" post some crap, there's angelic right behind him to wipe his ass.

Whatever, I love the drama and misery I'm creating in their lives. It just shows me I'm unattentionally making an impact on people. I hope they're not losing too much sleep, because I know I'm not.