[wdmaudiodev] AW: AW: Re: AW: Re: Generic Virtual MIDI-driver...
- From: "Tobias Erichsen" <t.erichsen@xxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Mon, 30 Mar 2009 17:38:49 +0200
Hi Jeff,
since some of the WDM-mailing-lists message don't seem to be
received (or dropped) by my email-server, I have reactivated
my private account to continue this discussion and to not
miss any other messages like yours below ;-)
> I've recently done a bit of work involving dynamic subdevices with
> dynamically assigned friendly names, in the context of a digital radio
> (DAB+) capture card. Essentially what I do is use the system calls
> IoRegisterDeviceInterface, IoOpenDeviceInterfaceRegistryKey and
> ZwSetValueKey to create all the subdevice registry keys and values
> normally done by the INF file. In my case I use the 16-bit DAB Service ID
> number to uniquely identify each device I create, associating the
> broadcast friendly name with that device via the registry calls when the
> capture card detects a new service.
I had seen your original post concerning the dynamic subdevice
creation and hoped that you would be in on this as well :-)
It is good to know that you succeeded in doing this...
You don't happen to have a couple of lines of code that show what
kind of strings you hand down to the API-calls - this would really
be appreciated.
> There is a caveat to this method, though, that once established the
> friendly name for a particular subdevice ID is not so easily changed,
> as I believe it's cached elsewhere in the registry (at least on Vista).
> In my case this isn't an issue, as the friendly name associated with
> each DAB service ID is generally fixed, and all I really need to do is
> associate the name with the service ID in the registry when it's first
> encountered.
It should be possible to query any previous usage of an application-
specified friendlyname and just reuse that GUID and for every new
friendly-name a new GUID would need to be created - I guess that
should work - right?
Perhaps someone from MS could come in on this subject to give some
more insights into this storage/caching of previously used GUIDs...
> Regarding your final question, perhaps I'm missing something, but I
> don't see why defining custom property sets should be a particular issue
> with dynamic subdevices, as the property set automation tables are
> defined when each subdevice is created.
Since I want my dynamic subdevices to be created on behalf of an
application, I need to register a private control-device-interface
which I want to use to a.) create/destroy dynamic midi-ports
and b.) to transfer actual MIDI-data between the application and this virtual
midi-port.
Since some people already seem to have done this by "hooking" the
normal driver-entry-points and punting the unwanted calls to the
mini-driver with PcDispatchIrp, I guess that this is a valid
method to go by...
Best regards,
Tobias
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
******************
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.com/
Other related posts:
- » [wdmaudiodev] AW: AW: Re: AW: Re: Generic Virtual MIDI-driver... - Tobias Erichsen
