[wdmaudiodev] Re: audio driver questions
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Wed, 26 Aug 2009 16:35:07 -0700
Tim Newsham wrote:
>
>
> On Wed, Aug 26, 2009 at 12:10 PM, Tim Roberts <timr@xxxxxxxxx
> <mailto:timr@xxxxxxxxx>> wrote:
>
> However, one way to do what you ask is to make your "other device"
> into
> a bus driver. When it is ready to have audio services available, you
> call IoInvalidateDeviceRelations, which tells PnP to ask your driver
> about its child devices. You report the PnP ID for your audio device.
> The system will load your audio device, and it will start to run.
>
>
> ahh, thank you. I'll look into this.
>
>
> This is exactly what the USB bus driver does when a device plugs and
> unplugs. And, really, it's not that hard to do.
>
>
> Would this be suitable for two devices that are cooperating with each
> other (ie. in a master/slave relationship, akin to pseudo-ttys in
> unix)? If so, how would I establish a relationship between the master
> device (who would be playing the bus driver, I guess) and the
> dynamically created slave device that gets loaded when demanded by the
> master?
I believe that's exactly what I described above. Think of USB as a
model. The USB bus driver notices that a new USB device has plugged
in. It builds a plug-and-play ID from the device's descriptors, and
exposes it through the bus relations, as I described above.
Plug-and-play finds the driver in its INF files based on the device ID,
the driver is loaded, and everybody is happy. When the device unplugs,
the USB bus driver again notifies that its bus relations have changed,
and this time plug-and-play starts the removal process on the upper
level driver.
I think you're talking about the exact same model. Note that you can
make the plug-and-play ID be whatever you want. USB happens to use
USB\VID_xxxx&PID_xxxx, but that's just a convention. You could have
NEWSHAM\AUDIO, for example.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
