[wdmaudiodev] Re: WHQL for virtual audio driver

  • From: "Arthur Chung (RDCT)" <arthur_chung@xxxxxxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 12 Nov 2015 07:56:52 +0000

Hi,
I have a problem with Fidelity Test.
In the log, after listing my virtual driver's Endpoint Id, Devnode Id, Friendly
Name etc., there's an error, "Did not find a hardware ID for this audio device"
(testsrc\multimediatest\avcore\audio\multiapi\fidelity\proxy\deviceenumerator.cpp
Line:737).
In my INF file, the hardware ID is set as "*MyDevId", just like that in MSVAD
sample.
The same ID could be seen in DeviceManager.
I'm not sure whether the error means the same ID in INF file or what I am
missing here.

________________________________
從: wdmaudiodev-bounce@xxxxxxxxxxxxx [wdmaudiodev-bounce@xxxxxxxxxxxxx] 代表
Arthur Chung (RDCT) [arthur_chung@xxxxxxxxxxxxx]
寄件日期: 2015年11月6日 上午 08:16
至: wdmaudiodev@xxxxxxxxxxxxx
主旨: [wdmaudiodev] Re: WHQL for virtual audio driver


Thanks for your help.

I'll try RoundTrip test first.



________________________________
從: wdmaudiodev-bounce@xxxxxxxxxxxxx [wdmaudiodev-bounce@xxxxxxxxxxxxx] 代表
Matthew van Eerde [Matthew.van.Eerde@xxxxxxxxxxxxx]
寄件日期: 2015年11月4日 下午 07:21
至: wdmaudiodev@xxxxxxxxxxxxx
主旨: [wdmaudiodev] Re: WHQL for virtual audio driver

how could Microsoft do the same

The way WHQL works is you run the tests, submit the results and your
self-signed driver package, WHQL looks at your results, and then re-signs your
driver package.

Microsoft doesn’t have your hardware, so we don’t run any tests on our end to
verify anything before we sign.

(Well, in your case, I suppose we *could*, since the hardware is fake. But the
procedures were designed with real hardware in mind.)

is there any way to tell the test server(test kit) some tests are N/A?
Or how could I tell the test server that my device is unclassified, no need
to do all audio tests?

The test kit is smart enough (in principle, anyway) to *choose* precisely those
tests that are applicable.

If your driver exposes a KSCATEGORY_AUDIO interface, then it is by definition
an audio driver, and the audio tests should be run.

If you think you’ve found a situation where a test is incorrectly chosen as
applicable, when it shouldn’t be – or conversely, if you think a test that
should be applicable is missing – please let us know so we can fix it.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Arthur Chung (RDCT)
Sent: Tuesday, November 3, 2015 6:26 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: WHQL for virtual audio driver


My virtual mic could only be fed by my application using some proprietary
methods.
I could do the tests myself by following your instructions, but how could
Microsoft do the same to verify it?
Should I also submit my application to WHQL too?



Or is there any way to tell the test server(test kit) some tests are N/A?



Or how could I tell the test server that my device is unclassified, no need to
do all audio tests?

Microsoft signature only suffices my need, no logo is required.

________________________________
從: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[wdmaudiodev-bounce@xxxxxxxxxxxxx] 代表 Matthew van Eerde
[Matthew.van.Eerde@xxxxxxxxxxxxx]
寄件日期: 2015年11月4日 上午 10:05
至: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
主旨: [wdmaudiodev] Re: WHQL for virtual audio driver
I see.

Well, you can pass RoundTrip by following the instructions.

If you have a microphone endpoint, it will ask you to induce a sine tone on
that microphone endpoint.

For a physical mic, you would need a sine tone generator that you physically
placed next to the mic.

For a virtual mic that feeds from an application playing to some other
endpoint, you would need to find an application that generates a sine tone, and
point it at whatever playback endpoint feeds your virtual mic. For example, you
could use a YouTube video, or you could use the built-in sine generator wizard
in RoundTrip itself.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Arthur Chung (RDCT)
Sent: Tuesday, November 3, 2015 5:58 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: WHQL for virtual audio driver


Sorry for not making myself clear.
AP means user mode application as Tim said.



I've already made the audio pipeline working w/ the help of MSVAD and SYSVAD
samples.
My actual question is whether it could pass WHQL tests or not (for some tests
require physical connections).



The reason is I need to get Microsoft signature for silence installation
required by the user.
If I signed the driver myself, there will be a dialog asking something like "if
you trust the publisher..." (with a check box for "always trust").



________________________________
從: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[wdmaudiodev-bounce@xxxxxxxxxxxxx] 代表 Matthew van Eerde
[Matthew.van.Eerde@xxxxxxxxxxxxx]
寄件日期: 2015年11月4日 上午 01:52
至: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
主旨: [wdmaudiodev] Re: WHQL for virtual audio driver
I wasn’t sure whether Arthur meant “application”, “audio precision” (as a
colleague of mine suggested), or “access point” (e.g., perhaps the driver
functions as a Miracast receiver.) I’m still not sure, but like you I am
leaning toward “application”.

Arthur, can you confirm?

Tim, when you say a “pipe to user mode”, do you have in mind:

1. an audio playback endpoint that can be used by a dumb app (like
Virtual Audio Cable does it), or

2. a custom interface which the driver would expose to “in the know”
user-mode code?

The closest thing to audio routing that Windows supports today is the WASAPI
audio loopback interface. In principle a driver could be packaged with a
user-mode service which includes a WASAPI loopback client; this could deliver
the audio back to the driver via a custom mechanism, and the driver could do
whatever it liked with it (e.g., deliver it up on a recording endpoint.)

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: Tuesday, November 3, 2015 9:40 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: WHQL for virtual audio driver

Matthew van Eerde wrote:
OK, so this is an audio recording scenario.

You know, this is one of the more frequently requested scenarios in the audio
driver world. Has the Microsoft audio team given any thought to releasing a
simple skeleton virtual audio driver sample with a pipe to user mode? For
years we've had MSVAD, but that's a 20,000-line behemoth demonstrating a
thousand esoteric features that aren't germane to the simple non-hardware case.
And it was never obvious to the casual observer that CopyFrom and CopyTo were
the magic locations for tapping the audio streams. Now, we have SysVad, which
is even more complicated, and so far I haven't found where the magic tap
locations are.


That is - what is an “AP?”

That, in some parts of the world, is the accepted abbreviation for
"application".

--

Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>

Providenza & Boekelheide, Inc.

This correspondence is from Cyberlink Corp. and is intended only for use by the
recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination, distribution
or copying of this correspondence and any attachments, is strictly prohibited,
unless otherwise authorized or consented to in writing by the sender. If you
have received this correspondence in error, please notify the sender
immediately, and please permanently delete the original and any copies of it
and any attachment and destroy any related printouts without reading or copying
them.

This correspondence is from Cyberlink Corp. and is intended only for use by the
recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination, distribution
or copying of this correspondence and any attachments, is strictly prohibited,
unless otherwise authorized or consented to in writing by the sender. If you
have received this correspondence in error, please notify the sender
immediately, and please permanently delete the original and any copies of it
and any attachment and destroy any related printouts without reading or copying
them.

This correspondence is from Cyberlink Corp. and is intended only for use by the
recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination, distribution
or copying of this correspondence and any attachments, is strictly prohibited,
unless otherwise authorized or consented to in writing by the sender. If you
have received this correspondence in error, please notify the sender
immediately, and please permanently delete the original and any copies of it
and any attachment and destroy any related printouts without reading or copying
them.
This correspondence is from Cyberlink Corp. and is intended only for use by the
recipient named herein, and may contain privileged, proprietary and/or
confidential information, and is intended only to be seen and used by named
addressee(s). You are notified that any discussion, dissemination, distribution
or copying of this correspondence and any attachments, is strictly prohibited,
unless otherwise authorized or consented to in writing by the sender. If you
have received this correspondence in error, please notify the sender
immediately, and please permanently delete the original and any copies of it
and any attachment and destroy any related printouts without reading or copying
them.

Other related posts: