Drew Hoffman

Someone else had reported that DirectX 8.1 and 9.0 DXDIAG can crash when checking digital signatures. In your test with disabling/enabling the driver with DirectX 5: I have no idea what a STATESTS value of 0xBDF7 could possibly mean, the specification defines the high bit as Reserved, Always 0. The only thing I can think of to do if that happens is reset STATESTS and then reset the controller. e: no it has to be reading complete garbage instead of HDA controller registers, i should return an error as soon as the version number doesn't make sense. DirectMusic will always be user mode not kernel mode; my driver doesn't contain a MIDI synthesizer and relies on the stock general MIDI Microsoft GS Wavetable Synth. I'm currently exploring other ways of doing FM sound in DOS games (resurrecting the old VDMSound project) but it seems I will need to disassemble the port trapping VxD to add more features. It could use some buffering for port writes to reduce the synchronization overhead, it fails really badly with Diode Millliampere's Adlib Tracker music. e2: I don't know why in some of these dxdiag logs it lists my driver's name as "°" (0xB0 0x03), where can that be coming from?

The driver is supposed to support Windows 98 first edition in that I don't use any of the WDM APIs that are only available on later versions of Windows (such as Kernel Streaming Events) but there are known bugs with the WDM audio implementation on 98 FE such as sample rate and bit depth conversion not working, and problems with the Sound Blaster emulator driver. Microsoft doesn't recommend the use of WDM audio drivers for 98 FE. DirectX 8 and newer update some of the Windows Kernel Streaming audio components to support DirectSound. The DO_POWER_PAGABLE error could be printed by another driver you have installed or it could be 98 FE's immature ACPI implementation. I haven't tested much on 98 FE. The worst bug I need to fix with the current version is the choppy/silent audio when the stream is paused and unpaused with the play pointer in the last 15% of the buffer (so about a 1/7 chance). Not sure why this is happening at all, must be something within portcls.

Perhaps it was the ALC262 or 268 which needed the format set before powering on the node, now I can't remember. I think it's expected for 98 FE that WDM sound drivers won't work if they are disabled and enabled again without restarting. There are some known issues with the volume control failing to appear after installing WDM audio drivers listed in old Microsoft knowledge base articles. On Windows 98 SE you may need to install the WDM Audio Update hotfixes Q242937 or Q269601, not sure if these will install on FE. If you are using Windows 98 QuickInstall these hotfixes are already included. Not sure what is causing all the "the child FDO has not set DO_POWER_PAGABLE" errors in your logs but the FDO object addresses it's listing don't match the ones logged by my driver, does this still happen without my driver loaded at all?

Also sometimes the order in which the verbs are sent can matter. Some Realtek codecs like the ALC272 need to have a format set before the node is powered up, and some other codecs need to be powered up before they will respond to setting the format.

My driver should be writing verb $70c payload $02 to the speaker pin complex node $05 so that's not the problem. (I don't think writing $03 for BTL enable as well is necessary?) But it's not currently doing anything at all with the power node, is that necessary for this Analog Devices codec? I tested on a few more systems myself. Thinkpad T430, Wyse Cx0 and Acer Aspire One are all working now. For the netbook maybe I should put some time into making an I2C HID bus driver because there's no legacy PS/2 emulation for the trackpad on anything with the Insyde BIOS. Or maybe I should just go back to XP where there is working 3D accelleration and power management.

Thanks for testing! Think you can give me a debug log for the last 3? Some of these laptops are probably using GPIO for jack detect or the power amp turn on instead of the dedicated sense and EAPD pins.

Released WDMHDA Version Alpha-021 which adds headphone jack detection and improves communication with the codec. https://github.com/andrew-hoffman/WDMHDA/releases

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.

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

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