Abstract:
A stream class driver for use in a computer operating system functions together with a minidriver. The minidriver is associated with a particular design for an adapter, which is a hardware device that generates or receives streaming data. The stream class driver deals with common operating system tasks such as direct memory access, scatter/gather memory use and Plug n Play. The stream class driver is independent of the hardware design and can therefore function with any type of streaming device or external buses such as USB or IEEE 1394. The minidriver functionality is limited to only those functions required by the unique aspects of the hardware and for the minimum requirements of operation, thereby minimizing the complexity and burden of designing minidrivers for hardware devices.

Description:
This application is a continuation of application Ser. No. 08/994,674, filed Dec. 19, 1997 now abandoned. 

   TECHNICAL FIELD OF THE INVENTION 
   The present invention pertains in general to computer software operation systems, and more particular to a driver for a class of devices which generate or receive streaming data. 
   BACKGROUND OF THE INVENTION 
   A rapidly growing area of interest in the field of computer technology is that of “multimedia”. This term generally refers to the concurrent use of video and audio in a computer system for a wide range of applications including business and entertainment. 
   The primary applications which have led to the tremendous success of personal computers have been based on the power of these computers to process numbers in complex ways such as through spreadsheets, graphics, word processing and data bases. However, in such applications, the application program works with a discrete data file and typically works with only a small part of such a data file at any one time. Multimedia applications add a major new aspect to the processing of data by personal computer. This is the requirement to manage and process a continuous stream of data as opposed to discrete data files which are typically processed by an application program. The stream of data associated with a multimedia application is generally for too large to be loaded in memory, and in many cases the data is continuous with no predetermined end of the data. A further feature of multimedia streaming data is that it is sequential in nature and frequently is time dependent, that is, it must not only be processed in a specific sequential order, it must also be processed to produce precisely timed sequential events. 
   An example of multimedia streaming data is the output which is produced by a DVD (Digital Versatile Disk) apparatus. The contemporary DVD apparatus produces data using the MPEG-2 video and audio format. This output actually comprises three separate data streams which are video, audio and subpicture. Each of these streams requires separate processing, but the results of the processing must be time synchronized and generated at a predetermined absolute rate to obtain the desired results. Video and audio signals must be properly synchronized and timed to generate a viable multimedia presentation. 
   A standardized computer platform, including hardware and software, must be able to work with a large number of independently produced multimedia adapters, such as DVD players, video cameras, audio sources and ROM discs. Each of these products requires a separate, complex driver which functions to interface application programs through the computer operating system to the specific hardware in order to process the multimedia streaming data to produce continuous outputs. However, to accommodate the massive amounts of data and the extensive, complex processing of this data required for a successful multimedia application, the driver must be highly efficient, well designed and capable of performing a wide range of functions within the operating system and functions required by the application program. With the growing complexity of operating systems and the greater demands of application programs, it is very difficult for each independent producer of a hardware device, particularly for multimedia, to produce an efficient, current and effective driver for that product. Thus, there exists a need to reduce the burden of producing drivers for multimedia products. 
   In other areas of computer system operation, such as for pointing devices, for example, a mouse, it has been proposed to have a hardware independent driver associated with the operating system and have a hardware dependent driver provided by the hardware manufacturer for each particular device. See U.S. Pat. No. 5,465,364 entitled “Method And System For Providing Device Driver Support Which Is Independent Of Changeable Characteristics Of Devices And Operating Systems”. Pointing devices, however, do not have the same problems that are encountered with multimedia applications. The data rate for pointing devices is extremely low, the data processing is not particularly complex and the pointing device is generally a support aspect of an application program, in contrast to being an aspect that is a principle part of a multimedia application. 
   In view of the substantial problems encountered in the use of multimedia applications on personal computers, and the insatiable consumer demand for greater bandwidth and data processing sophistication, there is a need for a multimedia driver configuration which can efficiently handle the volume and complexity of streaming data while at the same time minimizing the burden and difficulty of driver design for the independent developers and manufacturers of multimedia products. 
   SUMMARY OF THE INVENTION 
   The present invention is a method of operation, and corresponding computer program units, for a stream class driver which is used in conjunction with a minidriver. The minidriver is associated with a hardware adapter which generates or receives streaming data. The operation of the stream class driver product begins with receiving of initialization data from the minidriver followed by registration of the initialization data for later use by the stream class driver. After registration, the stream class driver creates a device object for the adapter. The stream class driver then sends a command to the minidriver to initialize the adapter. Next, the stream class driver requests that the minidriver provide adapter stream information for all of the data streams handled by the adapter. The minidriver provides this information and the stream class driver registers the received adapter stream information. The stream class driver may then provide a command to the minidriver to turn off power to the adapter and then pages out the minidriver and subsequently awaits a data stream request. 
   Upon receipt of a data stream request, the stream class driver pages in the minidriver to active memory. A command is generated to the minidriver to turn on power to the adapter. The stream class driver provides a data stream open command and stream structure data to the minidriver as needed to open the data stream requested by an application program. Next, the stream class driver provides a stream read or as stream write command to the minidriver. Properties and control information in a predefined data format related to the stream request are transmitted from the stream class driver to the minidriver. Upon receipt of a data stream termination command initiated by an application program, the stream class driver provides a stream close command to the minidriver. Finally, the stream class driver provides an uninitialization command to the minidriver for uninitializing the adapter. 
   In a further aspect of the present invention, the stream class driver can open additional data streams for either reading or writing streaming data concurrently with the first data stream. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings in which: 
       FIG. 1  is a block diagram of a portion of a computer system illustrating the relationship of the streaming class driver in accordance with the present invention with an operating system, an application program, a related minidriver and an adapter which is an apparatus which handles streaming data, 
       FIG. 2  is a flow diagram illustrating the initialization of the streaming data adapter through functions carried out by the operating system, the streaming class driver and the minidriver, and 
       FIG. 3  is a flow diagram illustrating the steps that are carried out, after initialization, for requesting and terminating a data stream in accordance with the present invention. 
   

   DETAILED DESCRIPTION 
   The present invention includes a stream class driver for use in a computer operating system. The purpose of this stream class driver is to make the writing of hardware drivers (minidrivers) for streaming devices much simpler. The functions performed by the minidriver are limited to those functions which are unique or necessary for the associated hardware, while the stream class driver performs all of the functions which are not dependent upon the particular hardware implemented. 
   Terminology 
   The principal terms used in describing the functions, data structures, commands and other aspects of the present invention are defined as follows:
     1. AC-3: An audio standard for delivering digital audio developed by Dolby Laboratories.   2. ActiveMovie: A cross-platform API developed by Microsoft Corporation for developers of multimedia applications that provide a user-mode connection and stream architecture to support high quality digital video, high fidelity audio, and special effects, now termed “Direct Show”.   3. Adapter: a hardware device for generating, handling or consuming streaming data   4. API: Application Programming Interface—A set of routines that an applications program uses to request and carry out lower-level services performed by a computer operating system.   5. CSA: Connection and Streaming Architecture—A functional specification produced by Microsoft Corporation defining an architecture and interface for application programs using streaming data and synchronization tasks. This is kernel-mode streaming in WDM.   6. DLL: Dynamic Link Library—An API routine that user mode applications access through ordinary procedure calls.   7. DMA: Direct Memory Access   8. Driver: Kernel Mode used to either control a hardware device or to emulate a hardware device.   9. EISA: Extended Industry Standard Architecture, a 32-bit bus configuration developed as an extension of ISA.   10. Filter: An entity which performs a specified function and includes a collection of related connection points called pins   11. GUID: Globally Unique Identifier. A quantity which is unique and includes a current date/time and a sequence number and which is used to allow any party to create an identifier which will not overlap other identifiers similarly created.   12. IEEE 1394: A standardized serial bus for high speed data transfer.   13. IOCTL: I/O control   14. IRP: I/O Request Packet—Data structures that drivers use to communicate with each other.   15. IRQ: Interrupt Request—A method by which a device can request to be serviced by the device&#39;s software driver.   16. ISA: Industry Standard Architecture—legacy bus configuration for original personal computer design.   17. ISO: International Standards Organization   18. ISR: Interrupt Service Routine   19. Kernel Mode: The processor mode which allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.   20. Minidriver: A hardware specific DLL that uses a class driver to accomplish most actions through functional calls and provides only device-specific controls.   21. MPEG: Moving Pictures Expert Group—A standard for compression and transmission of digital video.   22. PCI: Peripheral Component Interconnect—A high-performance, 32-bit or 64-bit bus designed to be used with devices that have high bandwidth requirements such as the display subsystem.   23. Pin: A set of properties which describe a potential connection point to a filter.   24. PIO: Programmed input/output, which is much like a complement to DMA.   25. Plug and Play (PnP): An enumerator standard for automatically detecting and recognizing installed hardware, as defined by Microsoft Corporation   26. SRB: Stream Request Block   27. USB: Universal Serial Bus—A bidirectional, isochronous, dynamically attachable serial interface for adding peripheral devices such as game controllers, serial and parallel ports, and input devices on a single bus.   28. User Mode: The nonprivileged processor Mode in which application code executes.   29. VxD: Virtual Device Driver—A device driver that runs at the privileged ring 0 protected Mode of the microprocessor.   30. WDM: Windows 32 Driver Model—A 32 bit driver model based on the Windows NT driver model that is designed to provide a common architecture of I/O services and binary-compatible device drivers for both Windows NT and Windows operating systems for specific classes of drivers.   31. Windows NT Driver Model: The layered device driver model used under the Windows NT operating system (see “Inside Windows NT” by Helen Custer (Microsoft Press 1993)).   32. Windows NT: Refers to the Microsoft Corporation Windows NT Version 4.0 operating system, including any add-on capabilities and any later versions of the operating system.
 
Operational Description
   

   The operating environment of the present invention is illustrated in FIG.  1 . This drawing shows selected hardware and software within a personal computer system which is preferably a system using an Intel Corporation x86 microprocessor and a Microsoft Corporation operating system such as Windows NT. The present invention is used within the illustrated environment for supporting a multimedia application, such as an application program  20 . The present invention is directed to a stream class driver  22 , which is preferably included within an operating system  24 . The application program  20  interacts with the operating system  24  through an application programming interface (API)  26 . The operating system  24  includes the conventional features and operating aspects, not illustrated, which are well-known in the industry. A system bus driver  28  is a part of the operating system  24  and is used to provide communication through a bus  30 , such as a PCI bus used with personal computers. 
   The upper edge of a stream class driver  22  of the present invention is accessed through a CSA interface  32 , which is defined in “Windows Driver Model Connection and Streaming Architecture Design Notes and Reference”, published by Microsoft Corporation. This document, which is incorporated herein by reference, is a part of the “MEMPHIS” designated operating system documentation entitled Windows 98 Developer&#39;s Release Device Driver Kit (DDK). 
   CSA interface  32  is further defined in U.S. patent application Ser. No. 08/825,957, filed Apr. 4, 1997, entitled “Method And Computer Program Product For Reducing Inter-buffer Data Transfers Between Separate Processing Components”, which is incorporated herein by reference. 
   The class driver  22  can be embodied in a computer readable medium such as magnetic disk, optical disk or magnetic tape. 
   The lower edge connection to the stream class driver  22  is defined by a stream class driver/minidriver interface  34 , which is specified in detail herein and in the attached appendices. 
   A minidriver  36  communicates through the interface  34  with the stream class driver  22 . Minidriver  36  is a unique design corresponding to a hardware adapter  40 . The adapter  40  is preferably a device that generates or consumes streaming data, such as used in a multimedia application. An example of the adapter  40  is a DVD player which produces digital audio and video streams for a motion picture. 
   Minidriver  36  is a hardware-specific DLL that uses the class driver  22  to accomplish most actions through function calls, and provides only device-specific controls. The minidriver  36  registers each adapter, such as  40 , with the class driver  22 , and the class driver  22  creates a device object to represent each adapter  40  that it registered. This process is described in more detail below. Minidriver  36  uses the class driver&#39;s device object to make system calls. 
   The adapter  40  is connected to transmit and receive commands and to transmit and receive data through the bus  30 . In a typical implementation, the application program  20  is a multimedia application that uses streaming data provided by the adapter  40  through the bus  30 . 
   Operating system aspect  42  includes the minidriver  36 , which is unique to the adapter  40 , but when implemented with a particular computer system becomes a part of the operating system  24  of that computer. 
   The internal interface  34  between the class driver  22  and the minidriver  36  is primarily a set of function calls between these drivers. The class driver  22  controls the request flow, calling the minidriver  36  when access to the adapter  40  hardware is necessary. The class driver  22  is responsible for multiprocessor and interrupt synchronization. Once both the class driver  22  and the minidriver  36  are initialized, the minidriver  36  is passive and is called only by the class driver  22 . Most of the function calls from the minidriver  36  to the class driver  22  are low-level service requests. 
   The detailed description for the specific embodiment of the present invention presented herein includes the description in the appendices that follow. These are:
         Appendix I Stream Class Driver Functions (Stream Class Driver  22 )   Appendix II Minidriver Functions (Minidriver  36 )   Appendix III Stream Request Block (Interface  34  SRB)   Appendix IV SRB Command Codes For the Adapter (Interface  34  Device Code)   Appendix V Stream Specific Command Codes (Interface  34  Stream Command Code)       

   These appendices describe in detail the functions, data structures and commands for the interface  34 . 
     FIG. 2  illustrates the operation of the present invention in conjunction with the operating system  24  and minidriver  36  to initialize the multimedia aspects of the computer system in preparation for receiving a data stream request from application program  20 . As shown in  FIG. 2 , the steps of operation are divided in columns between the operating system  24 , stream class driver  22  and minidriver  36 . 
   The operating system  24  functional operation begins at a start point  50 . Next, step  52  is performed to power up the system and perform the conventional self tests which are well known in the personal computer industry. 
   After the system has been powered up and the operating system initialization process is performed, step  54  is executed in which an enumerator, such as Plug n Play detects the attached adapter  40 . When the adapter has been detected, the Plug n Play enumerator, in step  56 , loads into memory the minidriver  36  for the detected adapter  40 . In step  58 , the Plug n Play initiates the minidriver  36  DriverEntry routine, as described in Appendix II. 
   Further referring to  FIG. 2 , the next functional step carried out is performed by the minidriver  36  in step  60 . In this step the minidriver  36  calls the class driver  22  function StreamClassRegisterAdapter. (See Appendix I) The minidriver  36  further collects and passes the data structure termed HW_INITIALIZATION_DATA. This data structure is described in detail in Appendix II. 
   From step  60 , control is transferred to step  62 , which is performed by the stream class driver  22 . Within step  62 , the initialization data provided in the HW_INITIALIZATION_DATA structure is registered, that is, it is recorded in memory for use by the class driver  22 . Next, in step  64 , the stream class driver  22  creates a device object corresponding to the adapter  40 . The minidriver  36  will not create a device object, but instead will share the class driver  22  device object as needed. Only one device object is created per adapter. 
   In step  66 , the stream class driver  22  calls the minidriver  36  to initialize the adapter  40 . This is done by calling the minidriver&#39;s function HWReceivePacket with the command SRB_INITIALIZE_DEVICE. (See Appendix IV) 
   In step  68 , the minidriver  36  initializes the adapter  40  hardware by performing the required setup and loading in the adapter any code required for operation of the hardware. 
   In step  76 , control is returned to the streaming class driver  22  which calls the minidriver  36  for stream information. This is done with the command SRB_GET_STREAM_INFO (Appendix IV), which is sent to the minidriver function HWReceivePacket. 
   Upon receipt of the SRB_GET_STREAM_INFO command, the minidriver  36  in step  78  builds a hardware stream descriptor for all streams that are supported by the adapter  40 . This information is returned to the class driver  22 . In step  80 , the streaming class driver  22  registers the hardware stream descriptor in memory for future use. 
   Next, in step  82 , the stream class driver  22  generates a power off command which is transmitted to the minidriver  36  for the adapter  40 . (See Appendix IV) In general, the operating system  24 , with driver  22 , will turn off power to the adapter  40  whenever it is not being used, especially for battery powered computers. 
   The minidriver  36  receives the power off command in step  84  and turns off power to the adapter  40 . In many systems, particularly portable computer systems, the adapter  40  is a device which uses a relatively substantial amount of electrical power. By disabling the adapter  40  when not in use, system power will be conserved. 
   Control is returned to the stream class driver  22  in step  86  wherein the driver  22  pages out the minidriver  36  program so that it is no longer stored in active memory, thus freeing resources for use by the application program  20 , operating system  24  or other active applications. The device object is preferably closed, by closing its file handle, prior to paging out the minidriver  36 . Finally, the class driver  22  enters state  88  to wait for a stream request which requires use of the adapter  40 . 
   Upon completion of the steps shown in  FIG. 2 , the computer system multimedia subsystem has been initialized and set to be ready to use the adapter  40  for streaming data when needed. 
   Referring to  FIG. 3 , there is shown a series of interrelated operations carried out by the operating system  24 , class driver  22  and minidriver  36  after the multimedia subsystem has been initialized as shown in FIG.  2 . These operations are carried out to initiate and terminate a data stream request. A stream request  100  is generated by the operating system  24  in response to the application program  20 . The data stream request is provided to the stream class driver  22  which responds in step  102  to page in the minidriver  36 . This step loads the minidriver  36  into active memory. If the device object has been closed, it is opened prior to paging in the minidriver. If the minidriver  36  has not been paged out, step  102  is not needed. 
   In step  104 , the stream driver  22  sends a power on command to the minidriver  36  for the adapter  40 . This command is received by the minidriver  36  and in step  106  it turns on power to the adapter  40  by transmitting appropriate commands to the adapter  40  through the bus  30 . Steps  104  and  106  are not needed if power has not been terminated to the adapter  40 . 
   In step  108 , the driver  22  calls the minidriver function HWReceivePacket with the command SRB_OPEN_STREAM (Appendix IV) and further provides a data structure HW_STREAM_OBJECT. (See Appendix III) This data structure provides the information needed by the adapter  40  and minidriver  36  to service a stream command which will be received from the application program  20 . 
   Upon receipt of the stream open command, the minidriver  36  performs step  120  to activate the adapter  40  and open the specified stream. For the described example wherein the adapter  40  is a DVD, the specified stream could be the video stream. For other streams, such as audio, a new stream request  100  would need to be generated through the operating system  24  by the application program  20 . 
   When the step  120  has been confirmed, the class driver  22  sends either a stream read (SRB_READ_DATA) or a stream write (SRB_WRITE_DATA) command to the minidriver function ReceiveDataPacket, as specified in the HW_STREAM_OBJECT for the selected stream. The minidriver  36  receives and stores the read or write command at step  124 . 
   In step  126 , the class driver  22  sets properties and other control information for the selected stream by passing the appropriate stream request block (SRB) to the minidriver&#39;s ReceiveControlPacket function as specified in the HW_STREAM_OBJECT for the selected stream. 
   At step  128 , the minidriver  36  sets the properties and control information received for the selected data stream so that the data stream transfer proceeds as requested by the application program  20 . At this point, the minidriver  36  is responsible for the streaming data request until it notifies the class driver  22  that the request has been completed. 
   In state  130 , the class driver  22  waits for receipt of a stream termination command while the streaming data transfer proceeds between adapter  40  and application program  20 . 
   When the application program  20  has completed use of the specified data stream, a stream termination  150  command is generated by the operating system  24  and transferred to the class driver  22  at step  152 . In this step, the stream class driver  22  calls the minidriver  36  and sends a stream close command, SRB_CLOSE_STREAM, to the minidriver&#39;s HWReceivePacket function. In response to this command, the minidriver  36  at step  153  closes the specified stream. The transfer of data for the current stream is completed at an end state  154 . After step  153 , the class driver  22  may, optionally, close the device object, page out the minidriver  36 , and turn power off to the adapter  40 . 
   When the operating system  24  detects at step  155  that the adapter  40  has been disabled by the user, physically removed, or the system is being shut down, control is transferred to the driver  22  at step  156  in which the driver  122  calls the minidriver  36  and sends an uninitialization command SRB_UNINITIALIZE_DEVICE. In step  158  the minidriver  36  performs the actions needed to uninitialize the adapter  40 . The actions required are dependent upon the particular design of the adapter  40 , and will vary from one manufacturer to the next. After the adapter  40  has been uninitialized, the minidriver  36  operation terminates at the end state  160 . 
   While a streaming data request is being processed, the streaming adapter  40  may generate interrupts. When an interrupt is detected, the class driver  22  will call the minidriver  36  interrupt service routine, as described in Appendix II. All of the minidriver  36  functions are synchronized with the adapter  40  ISR. This is done to make the minidriver  36  nonreentrant. Nonreentrancy is accomplished by masking off the IRQ of the adapter  40  (and all lower priority IRQs) when code is being executed in any of the minidriver  36  routines. When a thread is executing in the minidriver  36 , no calls will be made to any other function within the minidriver  36 , including the ISR. This nonreentrancy holds true even on multiprocessor systems, making the minidriver  36  very easy to write. 
   Due to routine synchronization and request serialization, the minidriver  36  is multiprocessor safe and nonreentrant for low-to-medium-end hardware. The processing described above has correct file operation synchronization. For example, stream and adapter  40  opens are correctly serialized without having the minidriver  36  implement mutexes, semaphores, or events. AU low-level buffer management is handled by the class driver  22 . This includes allocation of DMA adapter object, as necessary, mapping of buffers and building scatter/gather list for DMA, and locking and flushing buffers appropriately in DMA versus PIO cases. All IOCTL parameter validation is performed by the class driver  22 . All requests are timed by the class driver  22  with a watchdog timer. 
   A particular advantage for the class driver  22  of the present invention is that it can work with a wide variety of streaming hardware devices such as MPEG, video capture, USB audio and video and IEEE 1394 audio and video. 
   In summary, a driver configuration for streaming data includes a stream class driver for performing system operations which are independent of the streaming data adapter and a minidriver which performs a minimum set of functions that are dependent upon the specific hardware design implemented for the adapter. As a result, the minidriver design is greatly simplified and can be more easily implemented for each of a large number of streaming class devices. 
   Although one embodiment of the invention has been illustrated in the accompanying drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the scope of the invention.