But I want Dolby 12.3 surround on my sb16 games!

ALC662 working on 98se (stock +patchmem only)

Tested : only basic windows sounds.
Current version.
Mobo is some China abomination ZX-H55M + I3 560

Released version Alpha-020 which destroys the Stream Descriptor when playback is stopped and recreates it when started again, which mostly fixes the problem of no or choppy sound when skipping through music tracks. There is still a similar issue with rapidly pausing and unpausing a stream that I haven't found a fix for.
Also added an AI content disclaimer to the first post as required by the new forum rules. (This project is NOT vibe coded, but LLM tools have been used in its creation.)

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

I am sorry, if I ask a dumb question. I have a bit of a problem understanding what the "High Definition Audio Architecture" actually is.

From what I read in this topic it seems to be something that the operating system needs to support to play sound or to record sound. It seems to be an alternative to AC'97. So there seems to be a need to support either AC'97 or to support the High Definition Audio Architecture in the operating system to play sound or to record sound. A lot of sound circuits/sound cards seem to support at least one of those 2.

Windows 98 does not seem to support the High Definition Audio Architecture out of the box, nor does it seem to be supported by Windows 2000 nor by Windows XP. However, there is a Windows update available for both, Windows 2000 and for Windows XP (KB888111) which installs Microsoft's implementation of a High Definition Audio Architecture driver. This Windows update does not seem to exist for Windows 95 nor for Windows 98.

However, once the update is installed the operating system still does not seem to have the capability to play sound or to record sound. However, once the HDAA driver is installed, some new devices appear in the device manager. The device manager knows that these devices were created by the HDAA driver but does not know how to handle them. So it asks for a device driver.

So my question is, if there is a need for a device driver, then why do we need a HDAA driver?

If I understood your project correctly, then it is not only a HDAA driver but also a universal device driver for multiple sound circuits/sound cards. It seems as HDAA is not enough, it seems as if there is a need for something extra, something sound circuit specific. So you packed both in your driver: A HDAA driver and a universal device driver for multiple sound circuits. Is this correct?

If it is correct, would it be possible, to use Microsoft's implementation of their HDAA driver together with a "light" version of your driver to play sound in Windows 2000 and Windows XP? Let's say we strip the HDAA driver from your project and install the update "KB888111" instead. There would probably need to be adjustments in your project to make the 2 components work together. But in an attempt to understand these components my question is: Would this be possible?

Something else I read but could not quite understand is the situation we have on a Windows 2000 computer or a Windows XP computer when the update is installed. If I understood the situation correctly, then your driver does not work when the update is installed. So one needs to deinstall the update first and then install your driver to get anything working at all. Considering this situation, would it make sense to actually release a "light" version of your driver for users of Windows 2000 and Windows XP? Or would the efforts on your side be so high that it makes more sense to ask the users to deinstall Microsoft's implementation of their HDAA driver?

Or maybe a solution would be to split your driver into 2 separate components/drivers. While Windows 98 users would need both parts, Windows 2000 users on the other hand would be able to use 1 part + KB888111.

Start me up wrote on 2026-06-04, 23:02:

I am sorry, if I ask a dumb question. I have a bit of a problem understanding what the "High Definition Audio Architecture" actu […]
Show full quote

I am sorry, if I ask a dumb question. I have a bit of a problem understanding what the "High Definition Audio Architecture" actually is.

From what I read in this topic it seems to be something that the operating system needs to support to play sound or to record sound. It seems to be an alternative to AC'97. So there seems to be a need to support either AC'97 or to support the High Definition Audio Architecture in the operating system to play sound or to record sound. A lot of sound circuits/sound cards seem to support at least one of those 2.

Windows 98 does not seem to support the High Definition Audio Architecture out of the box, nor does it seem to be supported by Windows 2000 nor by Windows XP. However, there is a Windows update available for both, Windows 2000 and for Windows XP (KB888111) which installs Microsoft's implementation of a High Definition Audio Architecture driver. This Windows update does not seem to exist for Windows 95 nor for Windows 98.

However, once the update is installed the operating system still does not seem to have the capability to play sound or to record sound. However, once the HDAA driver is installed, some new devices appear in the device manager. The device manager knows that these devices were created by the HDAA driver but does not know how to handle them. So it asks for a device driver.

So my question is, if there is a need for a device driver, then why do we need a HDAA driver?

If I understood your project correctly, then it is not only a HDAA driver but also a universal device driver for multiple sound circuits/sound cards. It seems as HDAA is not enough, it seems as if there is a need for something extra, something sound circuit specific. So you packed both in your driver: A HDAA driver and a universal device driver for multiple sound circuits. Is this correct?

If it is correct, would it be possible, to use Microsoft's implementation of their HDAA driver together with a "light" version of your driver to play sound in Windows 2000 and Windows XP? Let's say we strip the HDAA driver from your project and install the update "KB888111" instead. There would probably need to be adjustments in your project to make the 2 components work together. But in an attempt to understand these components my question is: Would this be possible?

Something else I read but could not quite understand is the situation we have on a Windows 2000 computer or a Windows XP computer when the update is installed. If I understood the situation correctly, then your driver does not work when the update is installed. So one needs to deinstall the update first and then install your driver to get anything working at all. Considering this situation, would it make sense to actually release a "light" version of your driver for users of Windows 2000 and Windows XP? Or would the efforts on your side be so high that it makes more sense to ask the users to deinstall Microsoft's implementation of their HDAA driver?

HD Audio is split between the Controller (inside the chipset) which sends and receives audio data over a serial bus, and the Codec, a separate chip which contains the DACs and ADCs and optionally some vendor specific post processing stuff. AC97 is a similar design but not compatible with HD Audio, though some chipsets like the Intel ICH6 can use either type of codec depending on the choice of the motherboard manufacturer.

Here's Microsoft's description of the UAA Architecture: https://learn.microsoft.com/en-us/windows-har … io-architecture

The Microsoft UAA update includes the Controller driver which creates a new bus in the Device Manager that the vendor-specific Codec drivers can attach to. This would be something like "Realtek HD Audio Codec". The update also includes a few basic codec drivers as well but only for the first generation codecs that were available in 2004 when the update came out like the ALC660 and ALC880. Realtek bundles the UAA architecture update with their HD Audio driver package for Windows 2000/XP and it will be installed first if the system does not already have it so that Realtek's codec driver can work.

My driver can still work on a Windows 2000 or XP system with the KB888111 update installed, it just needs to be installed on the "Microsoft UAA Bus Device" in the System section in place of Microsoft's driver (and then the UAA Bus section of Device Manager will disappear).

Would a basic universal codec driver for Windows 2000 or XP serve a purpose? I thought people were able to use older XP versions of Realtek drivers and then edit the INF files to add the device IDs of newer codecs.

Bus > device.

You need a USB driver (bus) before you can use a mouse.
You need a PCI(e) driver before you can use a GPU.
You need a HDA bus driver before you can use an audio codec.

The bus drivers are bundled with the OS when they exist before the OS.
You might think PCIE is an exception because it works in 9x, but it is only a physical rearrangement of the underlying PCI bus standard - kinda like how wifi is a different physical form of ethernet (layer 1 of OSI).
LPC is similar. It is ISA with a new layer 1.

If it looks like a duck, quacks like a duck, and walks like a duck, the OS treats it as a duck.

HDA is a unique bus.
It isn't ISA, PCI, serial or any other prior bus protocol with a new layer 1.
It isn't even an extension of AC97 though there are some similarities.

So, like USB2/3, it needs a driver for the bus or your mouse (sound) is invisible.

This project has thusfar bundled the bus and codec together into one driver.

XP was firmly within the era of HDA. It got a driver.
2k is similar enough to XP, and had overlapping support eras that "backporting" was trivial, or more or less happened by accident. (Eg, something needed updating, and it is generally simpler to work on one main branch of software at a time, so the necessary changes to 2k were unified with a combined 2k/XP update).

Clear as mud?

onethirdxcubed wrote on 2026-06-04, 23:55:

My driver can still work on a Windows 2000 or XP system with the KB888111 update installed, it just needs to be installed in place of the UAA Bus driver (and then the UAA Bus section of Device Manager will disappear).

Is it correct, that the device that I marked with "(1)" in the screenshot is a audio controler circuit. At the moment Microsoft's driver from KB888111 seems to handle it. Is this device from Intel Corporation and inside the same chip/IC of the SOC (system on chip) as my processor and my graphics circuit is? Does the CPU communicate directly with this circuit?

Is it correct that the 2 devices I marked with "(2)" in the screenshot are audio codec circuits. At the moment no driver seem to handle them. Are these devices from, let's say RealTek, and in a separate chip/IC on the motherboard? Does the controler circuit communicate with the codec circuit in the sense that the controler circuit is the courier service between the CPU and the codec circuit?

onethirdxcubed wrote on 2026-06-04, 23:55:

Would a basic universal codec driver for Windows 2000 or XP serve a purpose? I thought people were able to use older XP versions of Realtek drivers and then edit the INF files to add the device IDs of newer codecs.

Well, it would serve a purpose to split your driver into a controler driver and a universal codec driver if you support more or plan to support more codec circuits than what can be used by hacking some RealTek inf files.

Start me up wrote on 2026-06-05, 00:28:

Is it correct, that the device that I marked with "(1)" in the screenshot is a audio controler circuit. At the moment Microsoft' […]
Show full quote

onethirdxcubed wrote on 2026-06-04, 23:55:

My driver can still work on a Windows 2000 or XP system with the KB888111 update installed, it just needs to be installed in place of the UAA Bus driver (and then the UAA Bus section of Device Manager will disappear).

The attachment Image1.png is no longer available

Is it correct, that the device that I marked with "(1)" in the screenshot is a audio controler circuit. At the moment Microsoft's driver from KB888111 seems to handle it. Is this device from Intel Corporation and inside the same chip/IC of the SOC (system on chip) as my processor and my graphics circuit is? Does the CPU communicate directly with this circuit?

Is it correct that the 2 devices I marked with "(2)" in the screenshot are audio codec circuits. At the moment no driver seem to handle them. Are these devices from, let's say RealTek, and in a separate chip/IC on the motherboard? Does the controler circuit communicate with the codec circuit in the sense that the controler circuit is the courier service between the CPU and the codec circuit?

onethirdxcubed wrote on 2026-06-04, 23:55:

Would a basic universal codec driver for Windows 2000 or XP serve a purpose? I thought people were able to use older XP versions of Realtek drivers and then edit the INF files to add the device IDs of newer codecs.

Well, it would serve a purpose to split your driver into a controler driver and a universal codec driver if you support more or plan to support more codec circuits than what can be used by hacking some RealTek inf files.

Yes, it is correct that device (1) is the controller and devices (2) are audio codecs.

You would install my driver on device (1) using "Update driver" then "I will choose the best driver to install", select the folder where you unzipped my driver files, ignore the warning about no digital signatures. Then after it is installed the unknown devices (2) should disappear.

The CPU does not quite communicate directly with the HD Audio controller, it's connected over the PCIe bus (though this bus may be internal to the SOC in your implementation). To Windows 98 it is enumerated as a standard PCI device with class code 0403.

My driver only provides basic support for audio output and is not as good as any Realtek or IDT or VIA (etc) manufacturer packages, the point of creating it was to get any sound working at all on Windows 98 which doesn't support the Universal Audio Architecture and cannot run the Win2k controller driver. (It can be installed with the help of Rudolph Loew's WDMEX but the codec drivers will not load or attach to the controller bus and nothing will work. Windows 2000+ Plug & Play is very different from 9x.)

I already do support more than one codec on the HDA bus, which happens in cases like laptops with docking stations and also for audio over HDMI. Each codec just receives the same output stream and there is no separate volume control yet. The HD Audio bus also supports modem codecs, but came out too late for this to be useful and no one cares about that now.

Windows Vista and newer OSes already seem to include a generic audio codec driver but I don't know if that can be backported to 2k/XP.

onethirdxcubed wrote on 2026-06-05, 00:59:

My driver only provides basic support for audio output and is not as good as any Realtek or IDT or VIA (etc) manufacturer packages, the point of creating it was to get any sound working at all on Windows 98 which doesn't support the Universal Audio Architecture

You already reached quite something so far. For this you have my congratulations. I think it was the hardest part to get anything working at all.

What are your current plans for your driver?

I intend to keep adding as many missing features as I can, under the constraints of what Windows 98 supports. This includes support for microphone and line inputs, multiple output streams, headphone jack hotplugging detection, 4 ch and 5.1 ch audio, allowing a wider range of sample rates if the codec supports it, etc. I also need to improve the codec compatibility as some VIA and IDT codecs don't work yet.

I read a bit through the specifications of HD audio. However, I did not quite understand the situation with the codec circuits.

The specification defines the controller circuit rather detailed. It seems to be possible to write a controller circuit driver with more or less nothing but the HD audio specifications.

But I am not so sure whether it is also possible to write a codec circuit driver with nothing but the HD audio specifications. The document describes function groups and something it calls "widgets". However, you seem to need something manufacturer specific for every HD audio compatible codec circuit.

Could you say a bit about what is missing to write a driver that is compatible with a specific HD audio compatible codec circuit? Basicly, what prevents you from writing one codec driver that works with every codec? Thank you.

Start me up wrote on 2026-06-13, 01:39:

I read a bit through the specifications of HD audio. However, I did not quite understand the situation with the codec circuits. […]
Show full quote

I read a bit through the specifications of HD audio. However, I did not quite understand the situation with the codec circuits.

The specification defines the controller circuit rather detailed. It seems to be possible to write a controller circuit driver with more or less nothing but the HD audio specifications.

But I am not so sure whether it is also possible to write a codec circuit driver with nothing but the HD audio specifications. The document describes function groups and something it calls "widgets". However, you seem to need something manufacturer specific for every HD audio compatible codec circuit.

Could you say a bit about what is missing to write a driver that is compatible with a specific HD audio compatible codec circuit? Basicly, what prevents you from writing one codec driver that works with every codec? Thank you.

The public codec-specific information is going to be in the codec's data sheet, for instance the Realtek ALC887 or the IDT STAC9227. Each codec has several different input and output ports which can be connected to the ADCs and DACs inside the codec through some combination of mixers and amplifiers and selectors. At boot, the BIOS is supposed to send pin configuration verbs to the codec which list what type of physical connection each of the input and output ports has (ie. is it headphone or microphone or line-in or rear surround, is it on the front or the rear panel, is the jack blue or green or black). Sometimes there are proprietary vendor specific technologies (like microphone beamforming, audio DRM or Dolby Atmos) which aren't described in the public datasheet at all.

A universal codec driver has to read back all that topology information from the codec, connect the DAC to the mixer to the selector to the headphone output for instance, set the volume and gain on every node in that path, umute and turn on the amplifiers in the path, set the output sample rate, and so on.

There's some problems in that which may prevent one universal codec driver from working: The pin configuration sent by the BIOS is not always correct, the default routing may leave connections going in loops in which case my driver gives up when the path is too long, some manufacturers expect the commands to be sent in a different order than others, there are vendor proprietary extensions and nodes (which aren't supposed to be necessary just to use the codec but sometimes they are), sometimes especially for laptops there are proprietary GPIO commands because the volume control buttons might be connected though the HD Audio codec and so on.

Usually the only indication that there is an error in this process is that no sound comes out.

Now I've done the best I can with all of this but I don't have the resources of the Linux kernel developers, I'm not willing to copy a bunch of code from some other project that's not compatible with my licensing (like all of MPXPlay like SBEMU/VSBHDA use), and I don't have every piece of real hardware made in the last 22 years to test against. Maybe it's possible to find a solution for some people's nonworking hardware from the debug log messages but I need to invest more time in building a better codec dumper, node parser, and tools to poke at the codec from user mode so I don't need to keep recompiling the driver to test things.

There were also a lot of issues with getting the controller driver to work properly on very new systems to sort through first. If the controller isn't sending audio streams properly or can't communicate with the codec then nothing will work anyway. Windows 98 treats PCI Express like normal PCI and makes some assumptions about cache-coherency that aren't correct so on AMD Ryzen systems for instance there was only choppy and garbled sound until I added some inline assembly code to flush the audio buffer out of L2 cache after writing to it.

Released WDMHDA Version Alpha-021 which adds headphone jack detection and improves communication with the codec.

https://github.com/andrew-hoffman/WDMHDA/releases

@onethirdxcubed many, many thanks for your driver! I installed Alpha-021 on the coreboot/voodoo4 laptop ( Voodoo4 M4800 ) on Windows98 in ACPI mode, and it works!!! Haven't yet encountered any issues (only issue I had was that when playing sound, moving the mouse (USB) would cause the sound to start looping the last 2 seconds or so, and the mouse to stop working (and any USB devices for that matter). Rest of the system was responsive though. I had HDA and USB on the same IRQ, and after moving the HDA to a non-shared IRQ, it works without issues. Wouldn't blame the HDA driver, considering how cursed this whole setup is).