[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.
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/
Other related posts:
