Posted: Tue Mar 09, 2004 9:25 am
From Ron Kuper in the Cakewalk forum. Thought maybe you'd find this interesting.
The difference between various driver models boils down to how the driver's kernel-mode component talks to its user-mode component.
Quick aside: User-mode is where applications like SONAR, IE, Word, etc. live. Kernel-mode is the lowest level area in the OS, where OS features such as memory protection, thread scheduling, etc. are implemented. As in most modern OS's, you cannot directly access hardware in user-mode; you must be in kernel-mode. A "device driver" is the code whose job it is to live in kernel-mode and talk directly to the hardware.
Win32 Driver Model (WDM) is very thoroughly designed and documented framework that defines how kernel-mode drivers talk to hardware. Microsoft provides documentation, driver qualification, etc, for WDM drivers. Furthermore, for audio drivers, WDM provides a way for user-mode applications to talk directly to the kernel-mode drivers. This is the Kernel Streaming (KS) interface.
Thanks to this design, SONAR can implement it's lower edge (the part that talks to the driver) using the KS interface, knowing that any WDM compliant driver will behave in the expected ways.
By comparison, ASIO is pretty different beast. ASIO defines how an audio application can talk to an audio driver, but doesn't specify *anything* about how the driver is to be implemented. So a host can implement a lower edge that talks ASIO, and can usually get consistent behavior just like KS. But there are some subtle and important differences.
First, I said with ASIO you can "usually" get consistent behavior. The issue here is that ASIO doesn't have nearly the degree of documentation and support that WDM/KS has. Let's face it, Microsoft is an orders of magnitude bigger company than Steinberg. The documentation team for KS is probably bigger than Steinberg's entire development team.
For ASIO, the end result is that many driver vendors test ASIO under Cubase, and then declare victory. Because the ASIO specification is unclear in some places, different hosts behave differently, and without a qualification system there's no easy way to ensure consistent behavior.
The other subtle difference between ASIO and WDM/KS is that ASIO doesn't specify how the kernel-mode piece gets written. A vendor is pretty much left on their own to figure out how to write their .SYS driver.
Ironically, if an audio hardware vendor wants to write an ASIO driver, they'll probably grab the Windows driver development kit (DDK), and look up the chapter on writing kernel-mode audio drivers. This chapter is all about writing WDM/KS drivers!
So in many cases, an ASIO driver has a WDM/KS kernel-mode piece at its core. This means that SONAR can automatically talk to the driver through the KS interface. This point is crystallized in the "ASIO4ALL" driver, which takes the low-level KS interface and wraps it in an ASIO interface.
The difference between various driver models boils down to how the driver's kernel-mode component talks to its user-mode component.
Quick aside: User-mode is where applications like SONAR, IE, Word, etc. live. Kernel-mode is the lowest level area in the OS, where OS features such as memory protection, thread scheduling, etc. are implemented. As in most modern OS's, you cannot directly access hardware in user-mode; you must be in kernel-mode. A "device driver" is the code whose job it is to live in kernel-mode and talk directly to the hardware.
Win32 Driver Model (WDM) is very thoroughly designed and documented framework that defines how kernel-mode drivers talk to hardware. Microsoft provides documentation, driver qualification, etc, for WDM drivers. Furthermore, for audio drivers, WDM provides a way for user-mode applications to talk directly to the kernel-mode drivers. This is the Kernel Streaming (KS) interface.
Thanks to this design, SONAR can implement it's lower edge (the part that talks to the driver) using the KS interface, knowing that any WDM compliant driver will behave in the expected ways.
By comparison, ASIO is pretty different beast. ASIO defines how an audio application can talk to an audio driver, but doesn't specify *anything* about how the driver is to be implemented. So a host can implement a lower edge that talks ASIO, and can usually get consistent behavior just like KS. But there are some subtle and important differences.
First, I said with ASIO you can "usually" get consistent behavior. The issue here is that ASIO doesn't have nearly the degree of documentation and support that WDM/KS has. Let's face it, Microsoft is an orders of magnitude bigger company than Steinberg. The documentation team for KS is probably bigger than Steinberg's entire development team.
For ASIO, the end result is that many driver vendors test ASIO under Cubase, and then declare victory. Because the ASIO specification is unclear in some places, different hosts behave differently, and without a qualification system there's no easy way to ensure consistent behavior.
The other subtle difference between ASIO and WDM/KS is that ASIO doesn't specify how the kernel-mode piece gets written. A vendor is pretty much left on their own to figure out how to write their .SYS driver.
Ironically, if an audio hardware vendor wants to write an ASIO driver, they'll probably grab the Windows driver development kit (DDK), and look up the chapter on writing kernel-mode audio drivers. This chapter is all about writing WDM/KS drivers!
So in many cases, an ASIO driver has a WDM/KS kernel-mode piece at its core. This means that SONAR can automatically talk to the driver through the KS interface. This point is crystallized in the "ASIO4ALL" driver, which takes the low-level KS interface and wraps it in an ASIO interface.
It's something they never fixed.