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.

Page

  1   2   3