WDM Adoption

WDM is relatively new to most audio hardware vendors. It is much more like the NT driver model than the Win9x VxD model. This means that the many hardware vendors who haven't yet developed NT drivers will have to learn new technology in order to support WDM.

(Note that difference between the NT driver model and VxD driver model is the primary reason for the current dearth of NT drivers, including NT ASIO drivers. Building a driver for a new platform requires learning the DDK for the platform, regardless of which API the driver is meant to support or how crisply defined the API happens to be.)

We see the newness of WDM as an opportunity for the Windows audio community at large. We are at a point in time where many hardware and software vendors are simultaneously taking their first serious look at WDM. At times when everybody is "on the same page" it is easiest focus on working together towards building the best solutions for everybody.

Another opportunity presented by WDM is its synergy with Win2k. We have already suggested that Win2k is a more desirable operating system for audio because of its well-bounded interrupt latency. Win2k also has the benefit of support for advanced file management such as asynchronous disk I/O. Since Win2k has great potential for professional audio, and WDM is the driver model for Win2k, a large trends towards the adoption of WDM seems inevitable.

Is WDM the Answer?

The following table places desirable traits of an idealized audio streaming solution alongside the capabilities of WDM.

Resolving the Limitations of WDM

Fortunately, the WDM has a provision for driver extensions. The WDM DDK provides a function named IoRegisterDeviceInterface through which any kernel mode driver can "advertise" that it has custom behavior. A user-mode application can then query the system for registered drivers, and communicate directly with them via the user-mode DeviceIoControl function by sending I/O controls (IOCTLs).

This mechanism suggests a way to work around the KMixer issue in WDM. If all hardware vendors can agree on a common set of IOCTLs, and expose these IOCTLs as standard WDM registered device interfaces, then we have an ideal solution that all software vendors can use.

A further benefit of IOCTLs is that drivers use them as the underpinnings of their support for ASIO or EASI user-mode APIs. So a kernel-mode solution based on IOCTLs will be compatible with existing applications that support ASIO or EASI. In fact, any hardware vendor who is considering ASIO or EASI support under Win2k is going to have to build a mechanism like this anyway.

To summarize, an IOCTL solution provides low-latency audio across the board for all Windows audio applications. A solution based on WDM plus IOCTLs has all of the desirable properties mentioned elsewhere in the paper:

• Single kernel-mode driver component
• Usable within kernel mode as well as user mode
• Cross platform on Win9x and WinNT
• Easy to implement
• Very low latency
• Free of political or legal baggage

The Windows Professional Audio Roundtable

At the February 2000 NAMM show, Cakewalk sponsored the first annual Windows Professional Audio Roundtable. Among the attendees were representatives from NemeSys, Microsoft, Bitheadz, Emagic, IBM, IQS, Propellorheads, MIDI Manufacturers Association, Sonic Foundry, Sound Quest, Steinberg and Syntrillium. AMD, Creative/Emu, Crystal, Digigram, DAL, Echo, Gadget Labs, Guillemot, Lynx, Roland, Terratec and Yamaha represented the hardware community.

At this meeting, Cakewalk proposed using IOCTL extensions to WDM and enlisted the aid of the audio hardware community in creating an actual deliverable design. The initial response to our proposal was overwhelmingly positive. Cakewalk fully intends to see this project to fruition, and openly invites any and all companies to participate in the design.

Figure 1. Driver Componentry on Win2k/WDM

This figure shows the componentry given today's status quo of API and driver proliferation. Each component provided by the hardware vendor is drawn with a double outline. A total of 5 components is required.

Working from the top down, we see that a host application has a choice of 4 application program interfaces (APIs) by which it can communicate with the audio hardware. Each API is implemented within its own user-mode component, typically a 32-bit DLL.

To communicate with lower level drivers, each user-mode DLL uses an I/O control (IOCTL) interface. In the case of MME and DirectSound, these IOCTLs are defined by the WDM kernel-streaming interface. In the case of ASIO and EASI, these IOCTLs are left open-ended, which means each vendor implements their own "private" version.

The IOCTL interface talks down to a kernel mode driver. If MME, DirectSound, ASIO and EASI is desired, then 3 conceptually different kernel model elements are required. Finally, the hardware abstraction layer, a.k.a., HAL, strictly controls all hardware access.

Figure 2. Simplified Driver Componentry

This figure illustrates the reduced componentry that is possible with a shared IOCTL interface to the WDM mini-port. The hardware vendor needs only supply a single component with an extended IOCTL interface.

Because the single driver component is still a WDM mini-port driver, host applications will still enjoy access to the Windows APIs such as MME/wave and DirectSound, enabling support for wave editors, games and legacy applications.

For high performance low-latency streaming, the host application communicates directly with the adapter driver via the proposed open IOCTL extensions to WDM. Applications which need to talk to hardware the ASIO or EASI APIs can continue to do so by implementing a thin "wrapper layer" on top of the IOCTL interface.

Back To Page 1