[wdmaudiodev] Re: AVStream driver communication from user mode

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 17 Jun 2016 16:39:48 -0700

alexander ivash wrote:

Thats exactly what I need. Let say somebody created my filter via  
graphedit and now I need to feed it with some data from my app. I was  
expecting there might be no simple answer on this, so at the moment I'm  
thinking about assigning some 'Id'-s to all the filters created and then  
exposing this Id-s as properties to user level so every app can query it..  
And then use method / property / direct DeviceIOControl to pass all the  
necessary info to 'current' instance to allow it to 'dispatch' request to  
proper instance.. But it seems a bit ugly/weird, I just thought there  
might be the right way to achieve the same functionality..

Are you trying to reinvent ManyCam?

Really, all of this is under the control of your AVStream driver.  When
the graph starts reading, it's up to the driver return data.  It doesn't
much matter where the data comes from.  You can have it notify another
instance using inverted call, and maybe get some data back to forward. 
There are a lot of details to worry about that, of course, like what
happens if your feeder app hasn't checked in yet?

Also remember that you might not have to do any kernel code.  You can
write a plain old user-mode DirectShow source filter and register it as
an audio or video source.  After all, that's what ksproxy is doing. 
There are a few apps that refuse to connect up to a source without a
kernel driver, but it depends on what you're trying to do.

Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.


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: