[wdmaudiodev] Re: newbie questions about filter drivers

  • From: dprado@xxxxxxxxxxxxxx
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Mon, 18 Oct 2004 16:00:18 -0200

> "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.
> >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 ?



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


Other related posts: