USB Support in Windows CE 2-10 This section describes the different components of USB support for Windows CE 2.10. Note that the primary focus of USB support in Windows CE has been to enable the technology such that OEMs can expand on this support. To this end, Windows CE supports only the host side of USB, since that was the area that would benefit most from Microsoft® defining the interfaces and enabling the USB technology in Windows CE. In essence, Microsoft provides the USB system software and a sample mouse driver that uses it. Microsoft-Supplied Components Microsoft supplies the following USB software components: 1* The USBD module that is responsible for loading USB device drivers and managing resources in the USB subsystem. 2* The complete set of USBD Interface (USBDI) functions listed in the Universal Serial Bus Specification, Revision 1.0, that is exposed by the USBD module. The API set includes Transfer Functions, Pipe Functions, Device Configuration Functions, and Miscellaneous Functions. Full documentation on these functions is in the Windows CE Device Driver Kit. This API set allows OEMs and IHVs to write USB device drivers to support any USB-compliant devices. 3* A sample Open Host Controller Driver (OHCD) that works with OHCI- compliant USB Host controllers. Note that the sample OHCD is only provided for the CE/PC platform. OEMs will have to port the sample OHCD to their platform as part of their OAL implementation. To ease this effort, the OHCD is divided into two parts: a platform independent "model device driver" (MDD) and a small "platform-dependent driver" (PDD). This follows the MDD/PDD device driver model used by other Windows CE native drivers. Thus, OEMs only need to port the platform-dependent driver (PDD) part. In addition, if an OEM platform contains a UHCI-compliant Host Controller, then the OEM could write its own Universal Host Controller Driver (UHCD) to support UHCI controllers as long as its UHCD exposes the appropriate HCD interface to the USBD module. The OHCD sample is an appropriate model to use as a reference while developing a UHCD. 4* A sample MOUSE client device driver that is loaded by the USBD module and works with most generic USB mice. This is only provided as a sample for OEMs and IHVs to use as a reference while developing USB device drivers for their own USB devices. Source code for these components is available in the \wince\public\common\oak\drivers\usb directory in the Windows CE Embedded Toolkit. Header files are in the public\oak\inc and public\ddk\inc directory, and platform sample code is in the platform\cepc\drivers\usb directory. System Software Support Bus Enumeration: Windows CE supports enumeration of USB devices on the bus. The bus enumeration process consists of an interrogation sequence through which the HCD module acquires information from a connected device, assigns it a unique USB address, and sets a configuration value. This is a multi-step process. Once the enumeration is completed, the device is configured and ready to conduct, transmit, and receive transactions. At this point, the USBD module will attempt to load one or more client drivers to control the device, based on the information contained in the device and interface descriptors. If no suitable driver has been registered for the device, the user is prompted to enter the name of a driver to control the device. Power Management: When Windows CE issues a POWER_DOWN notification, the USB host controller hardware and all devices are suspended by the system. At the following POWER_UP notification, the USB host controller hardware is reinitialized and the USBD module unloads the client drivers for all the devices, enumerates the USB devices connected to the bus, and loads the drivers for those devices. Windows CE also provides support for bus-powered and self-powered devices. For both types of devices, the USBD module reads the power requirements of the device from the descriptor information and rejects the device if the maximum power threshold is exceeded. OEMs can set this current-draw limit through a registry entry. Hub Support: Windows CE supports connecting hub devices up to one level deep. Thus, referring back to the earlier diagram of a typical USB configuration, hubs can only be connected in Tier 1, and peripheral devices can only be connected in Tiers 1 and 2. Support for Transfer Types Windows CE 2.10 supports all four types of data transfers as required by the Universal Serial Bus Specification, Revision 1.0, to support a variety of devices. Device drivers for USB devices can use any of these transfer types that may be appropriate for the device: 5* Control Transfers. Control Transfers are bidirectional transfers that are mainly used by the USB system software to query, configure, and issue certain generic commands to USB devices. Control transfers can contain 8, 16, 32, or 64 bytes of data depending on the device and transfer speed. Control transfers typically take place between the host computer and the USB device's endpoint 0, but may use other endpoints in the case of vendor specific control transfers. 6* Isochronous Transfers. Isochronous Transfers are used for streaming data that is time critical and error tolerant or in real-time applications that require a constant data transfer rate, for example, an internet telephony application carrying a conversation in real time. Isochronous data requires guaranteed amounts of bandwidth and guaranteed maximum transmission times. For isochronous transfers, timely data delivery is valued much more than accurate or complete data transfer. 7* Interrupt-Driven Transfers. Interrupt-Driven Transfers are mainly used to poll devices to see if they have any interrupt data to transmit. The rate of polling is determined by the device, as indicated in the endpoint descriptor structure, and may be from 1 to 255 milliseconds. This type of transfer is typically used for devices that provide small amounts of data at sporadic, unpredictable times. Keyboards, mice, and joysticks fall into this category. 8* Bulk Transfers. Bulk Transfers are used for devices that have large amounts of data to transmit or receive and need guaranteed delivery, but do not have any particular bandwidth or latency requirements. Printers and scanners fall into this category. Even very slow or greatly delayed transfers are acceptable for these types of devices, so long as the data is all eventually delivered. Unsupported Features There is no support in Windows CE 2.10 for making the Windows CE platform itself appear as an USB peripheral to other host computers. That is, we do not provide any Function Drivers on the host or device side to connect a Windows CE platform (such as an HPC) to a desktop computer running a USB host. Windows CE 2.10 does not provide any Class Drivers for classes of devices. Examples of class devices include the Human Input Device (HID) class, Stream Class, and so on. However, class drivers are supported by the USB system software, so OEMs can write their own HID class drivers to support HID class devices and load them appropriately using the registry mechanism. Microsoft will not provide a wide range of drivers for USB devices in Windows CE 2.10. If an OEM wishes to support a particular USB device, then they will be responsible for writing a USB device driver to interface with the USBD module. A UHCI driver will not be included with Windows CE 2.10, but OEMs can write their own UHCI driver that uses and conforms to the USBD-to-HCD interface. Device Drivers for USB Devices This section describes the sequence of actions that takes place when USB drivers are loaded and the required entry points for all USB drivers, and briefly discusses the sample USB mouse driver included with Windows CE 2.10. Note that this section does not provided details on writing USB device drivers; that information is beyond the scope of this article and can be found in the Windows CE Device Driver Kit. USB Driver load process Similar to PCMCIA drivers, USB drivers are loaded via the registry mechanism. The USBD module is responsible for loading USB client drivers when a USB device is attached. The USBD module uses the HKEY_LOCAL_MACHINE\Drivers\LoadClients portion of the registry on the platform to identify the appropriate USB driver for a given device. The algorithm used by the USBD module to identify the appropriate USB device driver from the information in the registry is complex; full details are documented in the Windows CE Device Driver Kit. Note that the LoadClients registry key must be set up correctly so that your USB device driver will be loaded for your USB device; each installed USB device driver must have such a key in order to be recognized and loaded by the USBD module. The load strategy used by the USBD module provides a flexible framework that allows USB device drivers to be registered in different ways, depending on the scope of devices that they wish to control. For example: 9* USB device drivers can be loaded based on a vendor-specific ID. 10* USB device drivers can be loaded to control devices of a specific device class 11* USB device drivers can be loaded to control each interface on a device. 12* Complex devices that require more than one device driver can also be loaded. Required entry points for USB device Ddrivers All USB device drivers must expose a certain number of the following entry points in their DLL. These entry points will allow them to configure and set up the device connected on the bus or set up the registry. USBDeviceAttach This entry point is called when the USB device for some USB device driver is connected to the USB bus. The driver's implementation of this function can decline to control the device, in which case Windows CE will attempt to find another driver to handle the device. USBInstallDriver This entry point is called the first time that the USB device driver is loaded, and gives the driver a chance to create any registry keys that it needs. USBUnInstallDriver This entry point is called when the user removes the driver from his or her Windows CE platform. It is responsible for removing all registry keys created by the driver's USBInstallDriver function and releasing any other resources held by the driver. Full details about the syntax of these entry points can be found in the Windows CE Device Driver Kit. Sample USB mouse driver The Embedded Toolkit for Windows CE 2.10 contains source code for a sample driver for USB mouse devices. This driver uses interrupt-driven transfers. OEMs and IHVs are encouraged to use the mouse sample driver source code as the basis for other USB device drivers. Note that the registry is already set up correctly for the sample CE/PC platform to load the mouse driver, so that plugging in a mouse should load the driver. Testing USB Device Drivers There is no extensive USB test suite for Windows CE at this time. The sample USB mouse driver, the USB CD-Changer device driver for the Auto PC, and the USB 8x930Ax peripheral kit and evaluation board from Intel® Corporation can be used to assist in testing USB scenarios. These are the same methods that were used at Microsoft to test the USB system software for Windows CE 2.10. Further details on testing a USB system and the device drivers on an OEM platform are available in the Windows CE Embedded Toolkit. For More Information http://www.usb.org/—the USB Implementers Forum home page. This site contains the complete USB specification, Universal Serial Bus Specification, Revision 1.0. Anyone considering building a USB compatible device or designing a hardware platform that supports USB should read this specification. http://www.intel.com/—information on USB hardware and microcontroller chips, such as the 8x930Ax and 8x931xA series chips. Windows CE Device Driver Kit—complete information on writing device drivers for Windows CE. Windows CE Embedded Toolkit—complete information for building hardware platforms based on Windows CE. Send feedback to MSDN. Look here for MSDN Online resources. USB Speakers With the advent of USB, several companies have created speakers that connect directly to the computer through USB. A true USB speaker system has no analog inputs at all; the only connection is the all-digital USB connection from the PC. This enables the USB speaker to separate the analog components far away from the electrically noisy environment of the PC. USB speakers can also let the system know information about the speakers themselves, in the same way that a video monitor can. Systems that use USB speakers as the primary DirectSound device do not have the ability to perform hardware acceleration of DirectSound. All their mixing is done through WDM’s kmixer, discussed below. Windows Audio Driver Models and DirectSound Windows has changed the underlying driver architecture for audio devices. This is completed with Windows 2000 and all future Windows versions into the foreseeable future. In “old” DirectSound, the VxD driver model was used and all DirectSound mixing was done in Dsound.vxd, a virtual device driver. Dsound.vxd also provided fairly close access to the actual DMA buffer that the sound card used to receive data from the host CPU. This buffer is the well-known “primary buffer.” A DirectSound application could set specific properties of the primary buffer (like sampling rate and bit depth); this directly impacted the actual properties of the hardware itself. Under WDM, DirectSound no longer has “direct” access to the sound hardware (except in the case of hardware accelerated buffers). Instead, DirectSound talks to kmixer, (for kernel mixer). kmixer’s job is to convert the format of multiple audio streams to a common format, mix them together and send the result to the hardware. In a sense, it does what dsound.vxd did. One major difference is that, while dsound.vxd only mixed DirectSound buffer data, kmixer mixes all windows audio data. This includes audio data from application that use the WaveOut APIs. (kmixer is more sophisticated in other aspects as well, such as support for multichannel and high-resolution sounds, but we won’t discuss those here.) Since kmixer can mix WaveOut and DirectSound data simultaneously, the old rule that DirectSound and WaveOut can’t both be open at the same time is no longer true on systems with WDM drivers. Of particular importance is kmixer’s relationship with the audio hardware. kmixer is the only piece of software on the system that can determine the actual format of the hardware’s DMA buffer. It selects the format on the basis of sounds it is asked to mix. The simple rule is kmixer sets the output format to the lower of: 13* What the hardware will support. 14* The highest quality format of sounds that is asked to mix. This has one very important implication: DirectSound no longer sets the actual format of the hardware’s DMA buffer; kmixer sets it instead. For your application, this means that the hardware format (and associated performance) will be based on the data you actually try to play. If you play a 44-kHz file, kmixer will mix all data up to 44 kHz and ensure the hardware is running at 44-kHz. So, the overall system performance is dependent on the content you give to kmixer. (kmixer does some optimizations. For example, if you have 12 sounds at 22 kHz and one at 44 kHz, it will mix all the 22-kHz sounds together at 22 kHz, and then just sample-rate convert the aggregate to 44 kHz to minimize CPU consumption.) Note As an application developer, you don’t choose the driver model used. That is completely determined by the type of sound card, Windows version and particular driver the user has installed. For that reason, it is very important that you cover all the bases when testing your application. DirectSound might be using dsound.vxd or it might be using kmixer, and you should ensure your game behavior and performance are acceptable on both. What you need to test to ensure complete audio coverage is described below. DirectMusic and Hardware Acceleration With Windows 98, Second Edition, and Windows 2000, DirectMusic acceleration is available on systems that have a WDM driver that supports it. Because of potential differences in features between hardware and software synthesizers, you should ensure that you test your DirectMusic application on Windows 2000 and/or Windows 98, Second Edition with an appropriate DirectMusic accelerating WDM driver. At the time of this writing, cards based on the Yamaha DS1 audio chip have WDM drivers that support hardware acceleration of DirectMusic, and drivers are forthcoming from other manufacturers. Testing your Games (Audio-wise) Because of the changes in driver model between operating systems and the various styles of sound cards available, it is important that you test your application across a wide range of systems. In particular, you should test on both WDM and VxD systems, using both accelerating and non-accelerating sound cards. The following table shows which operating systems support which sound card driver models: Table 1. Operating system support for sound card driver models OS VxD WDM Notes Windows 95 Yes No Windows 98 Yes Yes* *WDM drivers do not support DirectSound acceleration. Windows 98, Second Edition Yes Yes Full DirectSound Support. DirectMusic support (WDM only). Windows 2000 No Yes Full DirectSound support. DirectMusic support. As you can see from the table above, Windows 98 and Windows 98, Second Edition support both WDM and VxD drivers. Which is in use depends entirely on the particular sound card used and the driver the end user happens to have installed. Following is a list of the various types of sound cards and driver models with which you need to ensure you test your game along with some popular cards. By testing on each of these six categories, you’ll be ensured that your application works properly and with appropriate performance on whatever system the user has. Table 2. Sound cards and driver models for testing games Examples Comments ISA Non-accelerating cards with VxD drivers SB16, OPL3, ESS 186x, Crystal 423x ISA DirectSound Accelerating cards with VxD Drivers AWE 32/64 Guillemot AEW 32/64 is an extremely popular ISA based card. PCI DirectSound accelerating cards with VxD Drivers Diamond MX300 (Aureal Vortex-based cards), Diamond MX400, Creative Labs SBLive, Crystal Sound Fusion, Yamaha 192XG, Guillemot MaxiSound Fortissimo Most common modern DirectSound accelerated scenario. All listed cards do 3-D. Non-accelerating cards with WDM drivers Examples: SB16, AWE, ESS 186x, Crystal 423x, Yamaha OPL3, USB speakers 1. USB speakers use WDM exclusively. 2. The Soundblaster AWE card, though capable of acceleration, does not support it through WDM drivers. DirectSound Accelerating cards with WDM drivers Aureal Vortex, Crystal sound fusion, Yamaha DS1 Others coming soon Shipping in Windows 2000. You can also get WDM drivers from the sound card or chip maker. DirectMusic Accelerating cards with WDM drivers Yamaha DS1 Others coming soon Shipping in Windows 2000. You can also get WDM drivers from the sound card or chip maker. Emulating Performance and the DirectSound “Hardware Acceleration” Slider Within the Windows 98 and Windows 2000 multimedia control, you can alter the performance of DirectSound on a system-wide basis. The slider can be reached by Settings->Control Panel->Multimedia->Audio->Advanced->Performance. There are four settings: Emulation, Basic, Standard, and Full. 15* Full—This provides complete DirectSound acceleration, including the enabling of IksPropertySet extensions. IksPropertySet extensions are sound card specific enhancements such as EAX. This is the default setting on Windows 98 and Windows 98, Second Edition. 16* Standard—This provides acceleration of DirectSound secondary buffers but disables any hardware-specific IksPropertySet extensions such as EAX. This is the default on Windows 2000. 17* Basic—This disables hardware acceleration of DirectSound secondary buffers. When set to Basic, all sound cards, regardless of capability perform as if there were no DirectSound hardware acceleration present. This option is useful if you want to emulate a non-DirectSound-accelerated sound card for testing purposes. 18* Emulation—This forces DirectSound into emulation mode, whereby DirectSound acts as if there is no DirectSound compatible driver on the system. All mixing is done by DirectSound in user mode, and the resulting data is written out to the WaveOut API’s. This typically results in a large increase in latency. Note that after you select this setting, you may need to reboot if you want to return to any other setting (Basic, Standard or Full). Conclusion The basic architecture of both sound cards and the Windows audio infrastructure has changed. Applications need to ensure that they take best advantage of whatever configuration the user ultimately has. This includes both ensuring maximum performance (for example, by not using both DSBCAPS_STATIC and DSBCAPS_LOCDEFER), and providing adequate testing on all common OS/Sound card/Driver model combinations. Windows 98 and later provide a control panel to alter the behavior of DirectSound in ways that can facilitate such testing. Send feedback to MSDN. Look here for MSDN Online resources. USB Testing 19* Case 1 – If the device has a hub, install the device drivers for both a test device and a known good device. 20* Case 2 – Integration testing consists of choosing likely configuration and running the tests listed in the Single Device Testing and Stress Testing section above. INstall each device’s drivers and attach in typical configurations. Verify that each device is working properly in the chain, and then proceed to add stress—more ignition cycles, more devices in the chain— until a device fails. Built on Thursday, January 25, 2001 . Windows CE Device Driver Kit—complete information on writing device drivers for Windows CE. Windows CE Embedded Toolkit—complete information for building. USB, since that was the area that would benefit most from Microsoft® defining the interfaces and enabling the USB technology in Windows CE. In essence, Microsoft