[wdmaudiodev] Re: Generic Virtual MIDI-driver...
- From: "Jeff Pages" <barefeet@xxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 30 Mar 2009 22:49:20 +1100
Hi Tobias,
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.
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 may not be relevant to your midi device, but with wave devices it's
important to create the wave and topology subdevices and connect them with
PcRegisterPhysicalDeviceConnection before calling PcRegisterSubdevice for
each one (and unregistering them in the reverse order when destroying them)
otherwise Vista gets quite confused.
This all works very well in practice, with the subdevices representing each
DAB service appearing and disappearing in the list of audio capture devices
when I plug and unplug the antenna, and a different set of named subdevices
appearing when I switch to another multiplex.
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.
Jeff
Tobias Erichsen wrote:
I'm currently working on a small stub-driver that is based on MPU-401,
DMusUART (and some hints from
DDKSynth & MSVAD) and I intend to add to this driver until my mission is
fulfilled ;-)
I'm creating my INF-file by taking hints from the MSVAD-inf and some other
INFs I found for MIDI-drivers
on the net...
I have a couple of questions concerning my quest:
1. Is it possible to write such a driver & the corresponding INF-file that
installs, but initially does not
register any subdevices? What would I need to specify in the INF-file to
get this going?
2. Do I need a topology for this kind of driver - I think I read somewhere
that for simple MIDI-drivers
a topology would not be necessary.
3. As I intend to have "real" dynamic sub-devices, I cannot specify any
friendly-names within the
INF-file, as I don't have any information about what those would be when the
port is added later on.
How would I go about implementing this?
4. If I understand the documenation correctly the custom KS properties
reference existing
sub-devices. As I intend to create those subdevices dynamically, I would
figure that I
would need to go the way as to implement custom IOCTLs & hooking the
appropriate
functions & structures in the driver-entry (hen & egg problem) - is this
assessment correct?
******************
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:
