Here is version Alpha-013 which rearranges a lot of the codec init code and tries to init all the Line Outs no matter what.

https://github.com/andrew-hoffman/WDMHDA/rele … s/tag/Alpha-013

My SFF with an ALC887 codec now produces some sound but it is garbled; small segments will keep looping until I do something that causes hard drive activity and then it will play a bit more into the buffer. It's possible that the interrupt is not firing or is being suppressed. The problematic system has most devices sharing IRQ 11.

Released Alpha-014 which ignores outputs marked as not connected by the BIOS pin configuration. This improves compatibility quite a bit. It now functions on Intel 915G /Realtek ALC880. Still investigating the garbled sound issue with newer post-2010 chipsets.

https://github.com/andrew-hoffman/WDMHDA/rele … s/tag/Alpha-014

e: I think I broke something on Atom systems between version 12 and 13, where it hangs on a blinking cursor after the Windows splash screen, and it's annoying because it doesn't happen if i have the driver disabled, change the version and then enable it after boot. So I can't see the crash in DbgView. Does anyone happen to have an industrial embedded Atom PC with a serial port?

There was a revision of HDA around that time.

Found it.
1.0a
https://www.intel.com/content/dam/www/public/ … ecification.pdf

1.0 Initial Release April 15, 2004
1.0a June 17, 2010

• Updated with DCN No: HDA001-A changes.
• Updated with DCN No: HDA002-A changes.
• Updated with DCN No: HDA006-A changes.
• Updated with DCN No: HDA011-A changes.
• Updated with DCN No: HDA012-A changes.
• Updated with DCN No: HDA015-B changes.
• Updated with DCN No: HDA016-A changes.
• Updated with DCN No: HDA017-A changes.
• Updated with DCN No: HDA019-A changes.
• Updated with DCN No: HDA022-A changes.
• Updated with DCN No: HDA024-A changes.
• Updated with DCN No: HDA034-A2 changes.
• Updated with DCN No: HDA035-A changes.
• Updated with DCN No: HDA036-A changes.
• Updated with DCN No: HDA039-A changes.
• Updated with DCN No: HDA041-A changes.
• Updated with DCN No: HDA042-A changes.

Errata:

• Clarified Input Payload Capability and Output Payload Capability Reset value is implementation specific.
• Clarified that Stream Descriptor n FIFO Size must be valid and static after every programming of data format register, as well as when RUN bit is set.
• Clarified that Stream Descriptor n BDL Pointer Upper Base Address register attribute is RO if not supporting 64 bit addressing.
• Fixed timing error in “Codec Discovery” section that SW should wait for at least 521 us (25 frames) after reading CRST# as „1‟ before accessing codec.
• Strongly recommend the default value for EAPD to be „1‟ in “EAPD/BTL Enable” section.
• Clarified the codec response expected for double Function Group reset command in D3cold state, but recommended no response for the first Function Group reset of the double Function Group reset command sequence.
• Clarified the reset value for FIFOS register is implementation specific.
• Clarified UR enable verb for function group node is conditional in the required support for verbs table.

Seeing as this is a WDM driver, can it work in 2K/XP? Or are there big differences between 98 and 2K audio drivers?

My driver should be able to work in 2k, though I think it would have to be recompiled and have some edits to the inf file.

However there's already a better Microsoft driver available for 2000 SP4 and up, because Microsoft backported the UAA Architecture with the KB888111 update. They didn't ever bring that to the 9x Windows versions, and even R Loew couldn't backport it because of some missing kernel features to let the HDA Bus driver create its own child bus for the codec drivers to attach to.

This is why my driver has to cover both codec & controller as one monolithic piece. Supporting every possible combination of controller and codec across the last 20 years is looking like an insurmountable task though. I will do my best but would appreciate testing and pull requests.

I took a look at the code briefly a while back, and as an amateur c++ coder I honestly didn't know where to start.

Any chance you can write more comments and/or a guide to the code?

I'm no dummy, but it would take me weeks to understand it enough to add anything.

It took me a few months to find and understand everything I needed to get this far so don't feel too bad about that.

A lot of the code is from the Windows 2000 Driver Development Kit sample drivers, the AC97 and Sound Blaster 16 WDM audio examples. So the first thing you will need to do is find that and install it in a Windows 98se VM. (Yes that is the official Microsoft solution, the WDM audio examples were removed from the 98 DDK because they are very buggy on 98 First Edition and I didn't want to write a VxD for a couple of reasons.) The samples are in C:\NTDDK\src\wdm\audio after you install the DDK. There are readme.htm files in each folder of sample code and a lot of documentation is installed as well, see the Driver Writer's Guide d_dwguid.chm and the Kernel Streaming guide d_kernel.chm in the C:\ntddk\help folder. Most of the code I have added and edited is in the common.cpp file.

I am also using some init code and the codec node parser adapted from a hobbyist OS "BleskOS" which you can find information about on osdev.org wiki and forums. Besides that, you will need to read the Intel HD Audio Specification a lot to understand what is going on.

Maybe I can walk whoever is interested through the process of getting a dev environment set up over Discord or something.

Better to put a line or paragraph for each file and/or function.

For the standard ones, just a note "unmodified from Ms ddk"
For the modified ones, each function would be good.

Preferably in a readme too.

I'm nowhere near the point of being skilled enough to write drivers, but someone is likely to help if it is faster to understand.

onethirdxcubed wrote on 2026-01-11, 21:43:

However there's already a better Microsoft driver available for 2000 SP4 and up, because Microsoft backported the UAA Architecture with the KB888111 update.

These drivers have problems with audio corruption on newer boards. Well, I'm not sure if the fault is in the microsoft layer (hdaudbus.sys, etc.) or with the realtek stuff. The realtek driver is much newer at least (also HUGE).

Fixed the page fault crash the hang at startup on Atom systems.

https://github.com/andrew-hoffman/WDMHDA/rele … tag/Alpha-014-1

bakemono wrote on 2026-01-12, 14:39:

onethirdxcubed wrote on 2026-01-11, 21:43:

However there's already a better Microsoft driver available for 2000 SP4 and up, because Microsoft backported the UAA Architecture with the KB888111 update.

These drivers have problems with audio corruption on newer boards. Well, I'm not sure if the fault is in the microsoft layer (hdaudbus.sys, etc.) or with the realtek stuff. The realtek driver is much newer at least (also HUGE).

Well, my driver also has problems with audio corruption on newer boards at the moment, and it MIGHT be for some of the same reasons. So looking into the UAA driver might help narrow down why the problem occurs.
As you know, the Realtek codec drivers use the Microsoft UAA bus driver hdaudbus.sys to set up the Controller and do all the communication with the Codec.
Both my driver and the Microsoft UAA 1.0a driver use the Link Position in Buffer register, instead of the DMA Position Buffer like Linux ALSA generally uses (source here).
Some other possible issues could be the use of PCIe No-Snoop Transactions which won't be seen by the CPU cache, or the conversion of Message Signaled Interrupts to legacy IRQs, which might coalesce multiple interrupts into one, destroy the 1 interrupt per period assumption and break timing in PortCls. Will have to try compiling my driver for 2k and XP and find out what the issues are.

Also, if you have sources for this being a known issue on newer chipsets, I'd like to see them because I couldn't find much from searching. (Also how new is newer? Post-Sandy Bridge or post 2014 with Smart Sound Technology?)

onethirdxcubed wrote on 2026-01-12, 18:07:

Also, if you have sources for this being a known issue on newer chipsets, I'd like to see them because I couldn't find much from searching. (Also how new is newer? Post-Sandy Bridge or post 2014 with Smart Sound Technology?)

I've heard vague rumors about it, but my own experience is that AMD A88x chipset (2013) is fine, while A320 (2017) has problems. The symptom is a somewhat random 'buzzing' that can happen when a program is playing audio. It can continue after audio has gone silent, eg. pausing Winamp. Muting the 'Wave' volume control does not mute the buzzing, nor do any of the other controls except the 'Master Volume'.

Looking at the audio output on a scope, I can see that the 'buzzing' is small blocks of old data which are repeating every ~31.6ms.

Buffer not being overwritten properly?

Eg
Write from 0-10
Read from 0-10 loop
Rewrite from 1-10 loop

A classic off-by-1 error?

Tried alpha-014 with an ALC662 and there is some sound, but it's distorted and loops like every second. But nevertheless this sounds very promissing ^^. It's an AM1B-ITX mainboard from Asrock.

Fujitsu D3003 with ALC663 isn't working at all. Maybe it is a conflict with the HDMI device, wich i can't disable completly. Maybe I should try an external Graphicscard. But expectations are low.

When you say "doesn't work at all", do you mean that the driver doesn't start with Code 10 or Code 12 and the little yellow exclamation mark, or do you mean that it installs and starts but doesn't play any sound (and may give an error message about audio codecs)?

That board has a serial port so if you wanted you could set up the kernel debugger (or use DbgView) and get me some information on why it is failing.

I mean, that I have an exclamation mark with code 11. Do you have a good guide to set up a serial debug environment? Or is there even an image, which i can flash with Win98-quickinstall?

Here's a guide for setting up a kernel debugger over serial: https://bikodbg.com/blog/2021/08/win98-ddk/ though it's written for VMs, and for physical machines you will need a 9-pin null-modem cable to connect them and a terminal program that can open a COM port on the client machine. (PuTTY 0.62 or newer is fine.)
You can also use DebugView for Win98 but for that you will need to have the HDA driver disabled, then restart and open DbgView, then enable the HDA driver. Otherwise the startup messages will be missed.
Use the HDA.sys in the obchk\i386 folder on Github for more debug output.
No, I'm not making QuickInstall images yet, though perhaps I should look into that since there are a few bugs I want fixed from the stock 0.9.6 images anyway.

I feel like the garbled audio issue has to be caused by some interaction between the legacy CSM and interrupts not getting delivered properly when the IRQ is shared. In the worst case I can stop using the buffer completion interrupts and just schedule a DPC every 10ms instead. Have not been able to test much on real hardware lately since I'm not at home.

onethirdxcubed wrote on 2026-01-21, 01:38:

I feel like the garbled audio issue has to be caused by some interaction between the legacy CSM and interrupts not getting delivered properly when the IRQ is shared. In the worst case I can stop using the buffer completion interrupts and just schedule a DPC every 10ms instead. Have not been able to test much on real hardware lately since I'm not at home.

Interesting. I noticed hdaudbus has IRQ 36 on the problem system, whereas on older systems it has IRQ 16. Not sure if that means something. Msinfo32 doesn't report that it's shared with anything. QueryPerformanceFrequency also returns different numbers between new and old systems. I went off on a tangent wondering if that was affecting KeStallExecutionProcessor, but that doesn't seem to be an issue.

I thought Windows 9x didn't support the IOAPIC at all and so was limited to IRQ 0-15?
That's the impression I got from this article at least.
It's also possible that it does do utilize the APIC but only when installed in ACPI mode which I have also had considerable trouble with on modern hardware. QuickInstall always deposits a system image set for non ACPI mode but it might rerun the hardware detection and enable ACPI if the install is moved to another system.
Message Signaled Interrupts (MSIs) are definitely not supported in 9x and those would show up in the OS as a negative interrupt number if they were. On a system which is using those for the HDA controller, the Legacy CSM has to support calling the legacy IRQ vectors when a MSI is received.

Another possible problem that's specific to HD Audio is that the Link Position in Buffer registers may not reliably advance for the play position in the audio buffer because it's mapped as physical registers inside the Southbridge and <complicated caching reasons here> .
There is additionally a DMA Position Buffer required in the spec where the HDA controller will write these buffer positions to system memory instead, which the Linux audio documentation at least says is more reliable on newer chipsets. The Windows XP and Vista HDA drivers at least claim they are using the LPIB register and don't require the DMA Position Buffer. My driver has up to this point been using the LPIB register only.

I have implemented the DMA position buffer in my driver with the latest couple of Github commits but I haven't been able to test it properly yet since VMWare and Virtualbox lack support for the DMA position buffer as far as I can tell and it never advances from zero. Will try to do some testing with real hardware this weekend. I need to rewatch Omores' tutorials on making a bootable 98 USB install.

ElTentakel wrote on 2026-01-17, 16:51:

Tried alpha-014 with an ALC662 and there is some sound, but it's distorted and loops like every second. But nevertheless this sounds very promissing ^^. It's an AM1B-ITX mainboard from Asrock.

I also tested a ALC887 on an am MSI B85M-E45 which has the exact same behaviour. I hope I find some time for a debugging Session of the D3003.