Hello Frank,
Thanks for the comprehensive reply.
I started out using an IOCTL interface but quickly realized that KS was a
*much* better idea. The result, a virtual sink to source audio driver, is
working nicely. Although a useful learning exercise the former will never
see the light of day.
Thx++
Jerry
Just confirming and adding to what Tim has already said:
The filename results from the Name passed from the driver to
PcRegisterSubdevice. Port Class eventually uses this Name as the
ReferenceString to IoRegisterDeviceInterface.
While there is a strong convention for Port Class drivers to use "wave" as
the name, there is definitely no OS requirement here. The driver and its INF
could use anything, as long as it's consistent between the driver and the
driver's INF. In fact, the Microsoft USB Audio driver uses something
different.
The AddInterface sections of the INF should match the name/reference strings
used in the driver. Strictly speaking, it's not required, but it's generally
useless to have an AddInterface section that adds an interface that is never
actually registered and enabled by the driver. Conversely, it's also
possible (but not common for audio drivers) to, at runtime, add all the same
interface information that's normally found in the INF. Then the
AddInterface section is not needed.
If you are trying to add some custom IOCTLs to your audio driver, you should
consider adding custom KS properties and/or events instead. Depending on
what you're trying to achieve, it might be easier to stay within the KS
framework instead of "popping out" to IOCTLs.
I'm curious what functionality you're trying to enable through these extra
IOCTLs. I understand you might not be able to reveal that publicly.
Regards,
Frank Yerrace
