[wdmaudiodev] Re: Yet more jack sense questions
- From: Yuk Lai Suen <YukLai.Suen@xxxxxxxxxxxxx>
- To: "'wdmaudiodev@xxxxxxxxxxxxx'" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Wed, 8 Sep 2010 20:32:22 +0000
Can you describe what you want to do?
If class driver cannot be installed on the device, that the device could/should
not pass Windows Logo by the UAA requirement, which means it cannot be shipped
with OEM who intend to get system logo. As Windows 7 started,
KSJACK_DESCRIPTION and KSJACK_DESCRIPTION2 are required on all logo'd drivers.
It was not the case for Windows Vista. Is the IDT driver you have Win7 logo'd?
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of
Edward_Averill@xxxxxxxxxxxx
Sent: Wednesday, September 08, 2010 1:16 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Yet more jack sense questions
Ok, the plot thickens. I see both a "High Definition Audio Device" and an
"IDT High Definition Audio CODEC". "High Definition Audio Device" has
hdaudio.sys loaded for it (among other things).. so I uninstalled the IDT
device, rebooted, see that only "High Definition Audio Device" is active.. but
all but my HDMI endpoints have vanished.
I'm starting to think that the IDT audio device is somehow non-standard and
that their codec somehow makes things work, but possibly in a way that requires
a different approach to get to the data (urgh).
I'm starting to be convinced the only "reliable" way to get to the actual
status will be to write some kind of driver that sits on top of hdaudbus.sys,
but that's currently a bit beyond my knowledge level, and the one example I saw
assumed you already had a pointer to the FDO you could use to query for the DDI
data.
Time to book some lab time with more machines.
..ed..
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Matthew van Eerde
Sent: Wednesday, September 08, 2010 11:24 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Yet more jack sense questions
The driver may not be bubbling up the jack sense state to the
KSJACK_DESCRIPTION structure. Try installing hdaudio.sys and rerunning your
sample code.
http://blogs.msdn.com/b/matthew_van_eerde/archive/2010/08/23/troubleshooting-how-to-install-the-microsoft-hd-audio-class-driver.aspx
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of
Edward_Averill@xxxxxxxxxxxx
Sent: Wednesday, September 08, 2010 9:18 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Yet more jack sense questions
Ok, running Vista, I have some sample code that goes out, enumerates
endpoints, gets a KSJACK_DESCRIPTION for each jack, and prints IsConnected.
That was the easy part..
What I'm seeing is that EVERY endpoint says it's connected. Ok, fine, this is
a Dell laptop and it's possible the onboard audio doesn't support jack sense
(in which case it'd always return connected, according to the docs). BUT (you
knew there was a BUT, right?)..
..when I stick a jack in to LINE IN, the little applet that shows jacks etc.
pops right up and knows I just shoved it into LINE IN. The status my program
prints doesn't change, but somehow the applet knows. Ok...
So, is it possible that there's something device-specific in the applet that
lets it get the info reliably OUTSIDE of the standard API? Or does registering
for status changes somehow interfere with other apps ability to reach out and
look at the current state of the jacks?
Comments, suggetions, MSDN pages? All info appreciated.
..ed..
Other related posts:
