> "Shouldn't" is an awfully judgemental word :) . However, that isn't the > right way to do things. In general, the flow from top to bottom is > upper filter, function driver, lower filter. As long as that order is > maintained, it doesn't much matter what you call them. IRPs go into the > top driver, and come out the bottom. However, the naming doesn't really > change the roles. Regardless of how you did the naming in the registry, > your passthrough really is an upper filter to MSVAD's function driver, > and you probably want to continue to think of it in that way. ok. > >Generally, If I have a filter driver "XYZ" as an UpperFilter to a function > >driver "ABC" , can I install "XYZ" as a function driver and have the "ABC" > >driver as a lowerfilter to XYZ? Would it have the same effect? > > > > > > Theoretically, the passage of IRPs through the stack will be the same, > but why would you want to? Call a spade a spade.. I understand that some times filter drivers are used, to change functionality of a lower driver due to , let's say , non compliant hardware. But, I imagine, that there are situations where you want to filter IRPs to slightly change some functionality. The reason I wanted to do thing this way, is to be able to selectively use the filter driver or the original driver without filtering. If I register a filter driver ABC as a function driver and stack it on top of another function driver XYZ , any audio App can use waveOut api to write directly to the original XYZ driver, or write to ABC and have a "filtered XYZ through ABC". I don't know if this is clear or not, or even if it makes any sense at all. :) > >This same setup did not work when using USBaudio as a LowerFilter to the > >passthough driver The passthough driver refused to load. > > > > Did you actually have a USB Audio Class device to experiment with? > Remember that MSVAD is the bottom of its driver stack; there is no > lower-level bus driver underneath it, which is why it has to be loaded > by hand. That's not the case with USBAUDIO. It can only be loaded upon > a demand by USBD.SYS. There must be hardware underneath it (or > something that looks like USB audio hardware). That might have been the > difference. yes we had a usb hardware and usbaudio.sys was loaded and working. The filter driver on the other hand was disables and enabled by hand. I did not install it whith any hardware keys related to the USB device I was using. Maybe that's the problem, since the PNP system is not trying to load it, and manually loading will not work ( should it work, since the lower driver ( usbaudio) was loaded ? ). Dimitri ****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.de/