I can confirm it works better on ME in Virtualbox than the other 3.1 HDA driver.

Released a new version fixing the IRQ sharing bug so this should load properly on a lot more systems. Time to test on a lot more thin clients

Hello everyone!... I really wanted to say that this project to port HD audio to Windows 98 seems great to me, since I'm currently using Windows 3.11, but I'd like to be able to install Windows 98SE on a PC with an i3 4160 CPU, 4GB of DDR3 RAM, and a 40GB SATA hard drive... I hope I can get it working on my PC very soon!

Nice if HD Audio gets Win9x support.

I have a question... Can this driver run DOS games within Windows, using Sound Blaster emulation?

Like all WDM audio drivers, this uses the SBEMUL.SYS Sound Blaster emulation, so it will support DOS games with 8-bit digital sound and MIDI pass-through ONLY. No Adlib emulation. Overall the DOS support should be exactly the same as for USB audio if the driver works on your controller/codec. It Might be possible to improve this support using the Alpha version of VDMSound but I haven't tested it. If I wanted to trap the IO port to do Adlib emulation the driver would have to be a VxD and I haven't found many good references for developing a VxD.

Of course you can always reboot into DOS mode to run DOS games with SBEMUL or VSBHDA, and they will work on Windows 98's DOS as long as the memory manager is replaced with QEMM or JEMMEX. The easiest way to do this is to make a PIF file with custom config.sys and autoexec.bat.

At some point I would like to properly reverse-engineer SBEMUL.SYS. It reads a Registry key for a "SoftFM" parameter that seems to be a IO port address but it either doesn't do anything or breaks the emulation completely, and there is also a BLASTER string with type 6 that is referenced in the code but I don't know if there is any way to activate the Sound Blaster 16 mode in the released version.

Hmm. Possibly one of those cases where it worked for most things, but shit the bed for others and wasn't worth the support headache.
Wonder if it changed much between 95a,b,98,se,me.
Might have to do some poking around myself.

It seems it is only working for the Realtek ALC2xx at this time, for other Realtek codecs it is not finding the correct output pathway. Will troubleshoot more when I have a chance.

If anyone here is getting a resource conflict at 0000-3FFF like mskrzynski, please try the latest version of Patcher9x released a few days ago to correct the above 4gb resources bug. https://github.com/JHRobotics/patcher9x/releases/tag/v0.9.91

Thanks for this fantastic project!

Just tried this on a dell optiplex 760 with ICH10 HDA audio and Analog Devices AD1984A audio codec chip.

The driver installs without a hitch, but no audio output on any ports. I believe this is expected.

I also have a dell dimension e520 with ICH8 HDA audio and a Sigmatel STAC9227X5 audio codec chip. I haven’t tested this yet but understand I will likely see the same audio output issues.

Very much looking forward to more news 😎

onethirdxcubed wrote on 2025-12-26, 19:20:

It seems it is only working for the Realtek ALC2xx at this time, for other Realtek codecs it is not finding the correct output pathway. Will troubleshoot more when I have a chance.

Did you have a look at the win10 infs?
The verb architecture in the watler driver seems to be more or less similar to all the 'workarounds' in the infs.
I figured there might be some inspiration for different implementations in there.

Re: HDA Audio driver for Windows 3.1x

jamesfmackenzie wrote on 2025-12-30, 23:37:

Thanks for this fantastic project! […]
Show full quote

Thanks for this fantastic project!

Just tried this on a dell optiplex 760 with ICH10 HDA audio and Analog Devices AD1984A audio codec chip.

The driver installs without a hitch, but no audio output on any ports. I believe this is expected.

I also have a dell dimension e520 with ICH8 HDA audio and a Sigmatel STAC9227X5 audio codec chip. I haven’t tested this yet but understand I will likely see the same audio output issues.

Very much looking forward to more news 😎

Yes, same here. I assume proper audio routing is missing for other then 2xx Codecs. But I'm also looking forward for a wider support of Codecs 😀.

Yes I did have a look at the Windows 10 infs. The Windows UAA driver can accept a list of codec commands encoded as Registry keys though it's only supposed to be used for testing and not allowed for release builds. There is some more information in this book here. https://archive.org/details/highdefinitionau0000roac

I was thinking more like this bit

[HdAudModel_DellPrecision380.HdAudInit]
HKR,PinConfigOverrideVerbs,NumVerbs, 0x1,20,00,00,00
HKR,PinConfigOverrideVerbs,0000, 0x1,f0,1c,87,00
HKR,PinConfigOverrideVerbs,0001, 0x1,00,1d,87,00
HKR,PinConfigOverrideVerbs,0002, 0x1,00,1e,87,00
HKR,PinConfigOverrideVerbs,0003, 0x1,40,1f,87,00

Which to me looks very similar to the watler driver reassigning "ports/pins" for that particular codec.

I'm assuming that some devices don't report their capabilities properly as per the standard.
Which could be similar to your problem with whatever hardware you're testing.

On the msfn I think thread for that driver, someone had built a bunch of verb files for various hardware, and I'm guessing they're very much similar.

The node parser from "BleskOS" just does one pass through the list of audio function group nodes and picks one speaker out, maybe one headphone out, and a line or SPDIF out only if there isn't a headphone or speaker output at all. That's not fit for purpose on a desktop motherboard with the ALC887 because the only output with anything connected is a line out but it picks the unconnected speaker out first.

Mpxplay has a much better parser but I can't just use it directly even though SBEMU does, and I can't use the one from Watler's driver either for the same reason. There's no license at all included with the code. Just because someone has posted it to Github doesn't mean I can do anything with it.

If copyright meant anything, trillion dollar corporations wouldn't copy the entire knowledge of human history without asking

We're supposed to care about copyright here at Vogons, though the line that's drawn here does not always seem to be in the same place as the legal one.

No one has any problem linking to full images of Creative driver discs for instance, even though those have a lot of creative works on them besides the bare driver files needed for interoperability.

About seventeen years ago Creative used to send Cease and Desists to anyone who posted the full Audigy drivers because they were making money selling driver CDs to anyone who had a used card without discs, and now it's all on VogonsDrivers and no one is getting sued.

Heck, Microsoft uploaded most of their sample code for free to Github (and then trained their chatbots on it) when they used to charge thousands for development tools. It's generally considered better business now to let people make things for your product instead of suing your biggest fans. But the law is still the same as it was.

One solution could be a clean room implementation with LLMs. Create a documentation for the routing and then (or let a LLM) implement the code. The advantage would be, that other projects could benefit from that documentation.

And I fully agree. Just because no one cares today, that's no prof that no one will care tomorrow.

The coding LLMs were trained extensively on open source code and can easily reproduce the whole HD Audio section of ALSA already just for the asking. Does the GPL still attach if you have a LLM rewrite that code from memory? I have no idea and I don't think the legal system does either yet.

In any case Win98 can't support more than one output stream at the OS level so all I really need to do is set up as many paths as I can to stream 1, then keep a list of the paths and the volume control node & capabilities for each. Then I can apply the one volume control to every output for now. To add separate volume sliders for each output I need to change the Topology miniport to create more pins and then hide the ones that aren't present.

Perhaps Linux's HDA enumerator could be adapted?

This looks to my untrained eye like a function that might be useful.

1int azalia_codec_sort_pins(codec_t *this) {

https://github.com/openbsd/src/blob/master/sy … /azalia.c#L1901