IEEE 1394 Streaming Filter Driver Architecture (Windows CE 5.0)
The streaming filter driver takes advantage of a WDM concept of a type of device driver that is not specific to a particular piece of hardware, but that applies to a set of other drivers that share a similar concept or protocol. An easy way to consider it is sort of a DLL for device drivers. That is, it is driver-style code that can be shared and used by multiple drivers in the same way all at once without incurring its cost over and over again.
The following illustration shows a sample driver stack where an application communicates with a VCR subunit driver, and the subunit driver communicates with lower-level components, which communicate with even lower-level components, and so on, to complete the application's requests.
.gif "ms892192.1394avcstack(en-us,MSDN.10).gif")
An application is likely to need to control, transmit, and receive streamed media. This functionality can be included in a subunit itself, but that would require the same support to exist in every subunit driver for the subunits to remain even remotely compatible. This would also generate a complication in synchronization if bugs were fixed in one subunit driver, but not others. It is advantageous for all subunit drivers to export the same streaming API to applications, to use the same source for such code, and not to repeat code unnecessarily.
A filter driver is associated with a particular driver or class of drivers, and is defined as being an upper or lower filter driver. Whenever the targeted subunit driver is instantiated in a driver stack, the WDM code will automatically insert any filter drivers associated with the subunit driver into the driver stack.
The filter driver will be inserted either above or below the target driver, depending on whether the filter driver was defined as an upper or a lower filter driver, as shown in the following illustration.
.gif "ms892192.1394filter(en-us,MSDN.10).gif")
Filter drivers have the ability to intercept requests passing through them, filtering out requests that they choose to process. They also have the ability to provide common functionality if all drivers above them deal with unknown requests by properly sending the requests down to the next driver in the stack. The streaming filter driver works in exactly that manner. It exists as a lower filter driver, and expects all drivers above it to pass down unknown IOCTL commands. If the IOCTL commands are those known by the streaming filter driver, it will process them and complete them for the requester, which is usually the application. In this manner, a single driver that is shared by all subunit drivers encompasses all AV/C streaming functionality.
Send Feedback on this topic to the authors