[wdmaudiodev] AW: Re: AW: Re: Generic Virtual MIDI-driver...
- From: "Tobias Erichsen" <erichsen@xxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 30 Mar 2009 11:05:24 +0200
Hi Tim,
thanks for the response. Since I already have the stub-driver based on the
DMusUART and the MPU401 sample
running (just one static port though) I would prefer to implement it this way...
I have yet again browsed the mailing-list concerning the issue to create
dynamic sub-devices with a completely
dynamic (non-inf-file pre-defined) friendly-name.
There have been a real big amount of posts concerning this issue, both from
people writing audio as well as
midi-drivers (and both real-hardware-based as well as virtual software-only
devices).
Yet - there has not been any single instance where substancial help has been
given by the people from Microsoft
who are usually posting on this mailing-list?
Possibly this info has been given via private mail, but since these questions
seem to popup over & over again,
it would be helpful to clear things up once and for all...
So I dearly hope that I will finally get some feedback (and thus all people
craving for the answers) from some
guys from MS...
Best regards,
Tobias
________________________________
Von: wdmaudiodev-bounce@xxxxxxxxxxxxx [mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]
Im Auftrag von Tim Roberts
Gesendet: Freitag, 27. März 2009 22:20
An: wdmaudiodev@xxxxxxxxxxxxx
Betreff: [wdmaudiodev] Re: AW: Re: Generic Virtual MIDI-driver...
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?
AVStream is really an incredibly flexible platform. Anything that you
can do with the static data structures at installation and startup time can
also be done dynamically, after your device is running. That is, it's quite
possible to register yourself as "empty" at start up time, then add your
capabilities later on. Ks will update the dynamic parts of the registry as you
make your changes. There aren't necessarily good examples of this, but
browsing the Ks API may give you a hint.
What I DON'T know is how the audio architecture as a whole is interacts
with these kinds of dynamic changes. Will they recognize friendly names? Will
the more primitive APIs (like midiInOpen) catch any new sources? This is were
my empirical knowledge falls short.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
- » [wdmaudiodev] AW: Re: AW: Re: Generic Virtual MIDI-driver... - Tobias Erichsen
