schwups Posted June 6 Posted June 6 Looks like everyone who joined after November 23th are guests now with one exception. I see new members since Wednesday again. I believe the aim of this is to eliminate non-human members. I'm assuming he's human. So this can be temporary.
Drew Hoffman Posted yesterday at 02:10 AM Posted yesterday at 02:10 AM (edited) Guess I'm back for now, it took a while for my new account to be approved. I rewrote the controller initialization so now it shouldn't fall back into PIO mode and then stop actually sending any messages on NForce controllers. The CORB and RIRB communication also doesn't hold a spinlock the entire time it's waiting for a response. Attached is a version that deomsh can try and see if it works better on his NForce chipset with VIA codec. Tried to pull the jack detection PR I got but the combination of the DPC for jack polling and using a fast mutex to protect the CORB/RIRB communication function causes deadlocks on XP. It works OK on 98 though. Seems that I need to replace the DPC with polling from a kernel thread at passive IRQL, or do things properly and drive all the CORB/RIRB communication with interrupts instead of polling. wdmhda-20-change-init.zip Edited yesterday at 02:38 AM by Drew Hoffman
deomsh Posted yesterday at 11:31 AM Posted yesterday at 11:31 AM Tested on Windows 98 SE (DirectX 9.0c), no difference in performance, everything as reported earlier. To me the two logs produced seems to be almost equal as with version WDMHDA.020. WDMHDA.20a.N68_VT1705.zip
Drew Hoffman Posted 22 hours ago Posted 22 hours ago 7 hours ago, deomsh said: Tested on Windows 98 SE (DirectX 9.0c), no difference in performance, everything as reported earlier. To me the two logs produced seems to be almost equal as with version WDMHDA.020. WDMHDA.20a.N68_VT1705.zip 56.8 kB · 1 download Well that tells me that your HDA controller is like Vmware in that even with a longer timeout it will never set the bit to acknowledge CORB reset so always falls back to PIO. I have improved the PIO path to stop probing blindly if there were any codecs detected at reset, and have also added working jack detection polling in the latest version here (with some debugging help from LLMs unfortunately). I haven't tested this fully yet but it does work on at least 2 old laptops. WDMHDA-main-21a.zip
deomsh Posted 19 hours ago Posted 19 hours ago Congratulations, your WDMHDA v21.a is working now on my N68-board with codec VT1705. Also Master Volume is working. I made two set's of log's, one without Jack inserted (Fallback Playback-path is okay) and one with Jack inserted. I can not find a meaningfull difference in the log's in this respect. Is this logged somewhere? WDMHDA.21a.N68_VT1705.WIN982.zip BTW I added a log from a tool Isolar is working on currently, so you can see the Jack is really inserted in PIN-widget 1Ch.
Drew Hoffman Posted 17 hours ago Posted 17 hours ago 1 hour ago, deomsh said: Congratulations, your WDMHDA v21.a is working now on my N68-board with codec VT1705. Also Master Volume is working. I made two set's of log's, one without Jack inserted (Fallback Playback-path is okay) and one with Jack inserted. I can not find a meaningfull difference in the log's in this respect. Is this logged somewhere? WDMHDA.21a.N68_VT1705.WIN982.zip 92.29 kB · 2 downloads BTW I added a log from a tool Isolar is working on currently, so you can see the Jack is really inserted in PIN-widget 1Ch. At present it's only polling the first output pin which is listed as a Headphone Out in the BIOS pin configuration verbs. If you look at the log it shows that Node 1Ch is a Line Out pin complex and so the jack detection is not used. In your log Node 1Dh is the headphone out, this probably goes to the front panel audio header which may or may not be connected anywhere. If jack detection were working the log would show *WDMHDA: SwitchOutput -> SPEAKERS or *WDMHDA: SwitchOutput -> HEADPHONES. when the jack was disconnected/connected. For a desktop PC this seems to be the correct expected behavior but if there is more than one headphone out on a codec all of them should be polled, not just the first one. (There is a legacy assumption in the code that each codec can only have one headphone or speaker output.) Also need to add overrides to cover cases where the BIOS pin config verbs don't match the system's actual configuration.
deomsh Posted 6 hours ago Posted 6 hours ago Thanks, now I understand on how you are using the phrase "polling". BTW my boards Front Panel is not connected, I always use the green connection at the back.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now