Native (WDM) HD Audio driver for Windows 98se/Me

[deomsh]

Sound is good with Alpha-017.1 on Acer Verotin M2610G with 8086:1C20 and 10EC:0662.

All DirectX tests (only sofwarebuffering available) oke, except MidiMapper (HRESULT = 0x80004005).

Volume-slider in Windows 98SE default Mediaplayer is working too.

[Drew Hoffman]

Seems like setting the snoop flag on more AMD chipsets didnt really help, think I just need to WBINVD every time there's an IRQ and hope that flushes the cache enough. Unless someone can help me with ASM to get the audio buffer allocated as Write-Combine.

[SweetLow]

10 hours ago, Drew Hoffman said:

Unless someone can help me with ASM to get the audio buffer allocated as Write-Combine.

1. You should just ask

2. If in your build environment you can call VXD service (it is possible in .SYS too using some library from Windows 98 DDK AFAIK) then you does not need ASM at all. Else tiny stub is needed only.

P.S. Now I at my work environment.

The needed function is 

ULONG _cdecl _PageModifyPermissions(ULONG page, ULONG npages,
    ULONG permand, ULONG permor);

and as I said undocumented but official possibility is two PageCommit flags:

#define PC_CACHEDIS 0x00100000  /* Allocate uncached pages - new for WDM */
#define PC_CACHEWT  0x00080000  /* Allocate write through cache pages - new for WDM */

UC cache mode == PC_CACHEDIS |  PC_CACHEWT (PAT Index = 3)

And on processors with PAT support when MTRR.VXD is loaded:

WC cache mode == PC_CACHEWT (PAT Index = 1)

in the permor parameter. permand can be 0xFFFFFFFF or ~(PC_CACHEDIS |  PC_CACHEWT) - no matter as these flags can be set only and can't be reset.

Edited February 23 by SweetLow
P.S. added

[Drew Hoffman]

Calling the VxD service to modify the page permissions did not seem to work with this buffer and always returned -1. What did work for my Wyse Rx0 thin client was using MmMapIoSpace to provide a second mapping to the audio buffer's physical address but there is a warning in the developer documentation that it is undefined behavior to hold two mappings to the same memory with different caching types so I probably shouldn't release it like that and should find another solution to map the buffer myself in the first place.

There has been some progress with VIA codecs, I was cancelling initialization too early because the AFG node didn't report any supported formats. If I skip that part of SetFormat, the VIA codec produces max volume static from the left channel only and returns 0xc0000001 (unsupported) to all format change requests. It may need the nodes powered up before changing the format where on Realtek codecs a format needed to be set before powering the nodes.

[deomsh]

I just tested Alpha-017.2 with Asrock 960GM-GS3 on SB710/ ALC662.

Same as Alpha-016/017.1: first one or two notes of music seems to be heard, then repeat these endlessly. Different tone for different music.

Sound started only after disabling Master Volume and enabling again. No response on this volume slider, nor in volume slider of mplayer2. Mute button in mplayer2 did not work either. 

BTW no other sound drivers active.

[Drew Hoffman]

I haven't uploaded the version with the audio buffer allocation change yet because I wanted to confirm that it functions properly on all hardware with the technique I'm using, and if not I need to figure out how to call MmAllocateContiguousMemorySpecifyCache when it's not defined in the wdm header file and replace all the DmaChannel buffer allocation with my own. Also I'm trying to work on the VIA Codec problems separately.

If you want to try my in-progress version and see if it solves your issues on AMD 960/SB710, I've attached it here. Works on AMD SB600 but no guarantees it will be better for you.

Note: It seems this will crash on newer Intel and Ryzen systems so consider this AMD AM2/AM3 only!

WDMHDA-2026-02-27a.7z

Edited March 2 by Drew Hoffman

[deomsh]

Great, this driver-version, it is actually working on Asrock 960GM-GS3 (SB710/ ALC662). I tested wav, mp3, mid and rmi: all GOOD. 

Volume sliders are working and mute in Mplayer2 too (not available currently with Master Volume). I installed from Device Manager, Master Volume only popped up on Taskbar after disabling and enabling again.

Dxdiag: all tests succeeded (only software buffering available), including MIDI Mapper.

I checked playback speed with my stopwatch, seems to be correct.

 

[Drew Hoffman]

Great! I wanted to wait until I can get the driver working correctly on VIA codecs before posting another release on the Github page. Full volume static is probably worse than no sound at all for that case.

[SweetLow]

13 hours ago, Drew Hoffman said:

did not seem to work with this buffer and always returned -1

Check that this buffer is properly aligned. It's obvious that it works with aligned buffers only as its parameters are pages, not virtual addresses.

But IDK is it working for "partial" buffers - when you reserve large buffer ("pool") and then just take small parts from them.

And check the real page attrs (from PDE), of course, in case of any trouble. 

11 hours ago, Drew Hoffman said:

MmAllocateContiguousMemorySpecifyCache

It is not implemented in WDM and is NT specifiс. But it is easy reproducible through _PageReserve + _PageCommitContig + _PageModifyPermissions or (shorter version) _PageAllocate(PAGECONTIG | PAGEUSEALIGN ) + _PageModifyPermissions

Edited March 1 by SweetLow

[LoneCrusader]

MmAllocateContiguousMemorySpecifyCache is implemented in rloew's WDMEX. But it would have to be set up on a user's system prior to installing the driver.

I know the goal here is to build a 9x-specific driver and that is probably the best path if it's feasible.
But for the record, what role does HDAUDBUS.SYS play under 2K/XP for configuring the HDA devices?
Would it help your efforts to have this "bus" driver loaded under 9x?

[SweetLow]

17 minutes ago, LoneCrusader said:

what role does HDAUDBUS.SYS play under 2K/XP for configuring the HDA devices?

HDA driver model in NT is port/miniport. And HDAUDBUS.SYS is port driver. 

[SweetLow]

20 minutes ago, LoneCrusader said:

MmAllocateContiguousMemorySpecifyCache is implemented in rloew's WDMEX

Implemented or stubbed? There is no such list in WDMEX.ZIP but I remember that saw this list somewere.

[Drew Hoffman]

8 hours ago, LoneCrusader said:

MmAllocateContiguousMemorySpecifyCache is implemented in rloew's WDMEX. But it would have to be set up on a user's system prior to installing the driver.

I know the goal here is to build a 9x-specific driver and that is probably the best path if it's feasible.
But for the record, what role does HDAUDBUS.SYS play under 2K/XP for configuring the HDA devices?
Would it help your efforts to have this "bus" driver loaded under 9x?

HDAUDBUS.SYS is both a kernel streaming port driver and a bus driver for the HD Audio bus, and it's that second part that doesn't seem to work on NTKERN.VXD. It will not enumerate a new kind of bus it doesn't know about. 

Here's the thread where you were trying to get this working 10 years ago; even R Loew gave it up as impossible.

This is why my driver is monolithic and combines both controller & codec into one .sys file. If you want to look at the codec initialization only, all of that is now collected into codec.cpp after some refactoring.

I shouldn't need WDMEX for this purpose, I just need to implement that one allocation function in whatever way that WDMEX does (some combination of VxD and NTKERN functions I assume). If wdmstub implements MmMapLockedPagesSpecifyCache I can just copy however that does it (I have found the source code from the companion CD to Walter Oney's book already). Or I can just leave it the way I have it and hope that the extra mapping with a different caching type isn't actually a problem if nothing uses the memory through the cached mapping.

 

There is an open source HDA Bus driver that just got merged into ReactOS https://github.com/coolstar/sklhdaudbus if that would help with investigations.

I should also mention that there's a VxD HD Audio driver project that predates mine https://github.com/camthehaxman/hda9x

I was able to get this to build with Open Watcom 2.0 in Linux, and it does actually produce audio when run in Virtualbox but is extremely unstable and crashes after a few system sounds or one track change in Winamp. Unfortunately I think the author has abandoned it and never specified a license either.

Edited March 1 by Drew Hoffman

[LoneCrusader]

8 hours ago, SweetLow said:

Implemented or stubbed? There is no such list in WDMEX.ZIP but I remember that saw this list somewere.

I see it listed in the last version made public which is linked on the site rloew's son put up with released files.
Whether or not it is a full implementation or a stub I don't know.
Also I'd have to read back through our old communication to see if there are any relevant notes.

Needless to say though there were later builds of WDMEX. I just haven't had the knowledge, the time, or the heart to do anything else with them since Rudy passed away.

1 hour ago, Drew Hoffman said:

...bus driver for the HD Audio bus, and it's that second part that doesn't seem to work on NTKERN.VXD. It will not enumerate a new kind of bus it doesn't know about. 

Here's the thread where you were trying to get this working 10 years ago; even R Loew gave it up as impossible.

It wasn't given up as impossible. The OP of that thread was not interested in purchasing WDMEX, so the thread just fell by the wayside.
I will not debate the issue of free and paid software; it was his time and his knowledge to do with or not as he pleased. A moot point now anyway.

Since I was already a customer of WDMEX and various other patches, I had the opportunity to ask for more support of this and other issues (HDA and USB3 were our primary targets).
At some point after the discussion you referenced, we did succeed in successfully loading HDAUDBUS.SYS and having the HDAUDIO bus devices enumerated.
See screenshots on this page.
NOTE that the version linked there is the last version now made public, not the version this was achieved with. I wasn't thinking about that when I first created the page.

However, we hit a brick wall after that point. The Microsoft provided HDAUDIO.SYS file would not produce audio output under 9x, even when run on a HDA device that was specifically listed in the original INF.
Then we tried using specific HDA device drivers from Realtek, Sigmatel, etc. These always died in a series of BSODs when booting the system.
Debugging efforts with SoftIce on my end and his own debugger on his end always ended in a bunch of power related functions where he said it appeared as if the driver had already failed and was shutting down.
We were never able to get further on this before he passed away; and with him gone, I have no idea how to continue. Simply lack the knowledge, and the time to even attempt to learn.

[awkduck]

On 2/28/2026 at 7:57 PM, Drew Hoffman said:

working correctly on VIA codecs

This is one of the machines I intended to test; however you have one of the main machines (Wyse Cx0) I was interested in. I also have a HP t510 (VT8237A/VT8251 HDA/VIA Eden X2 U4200), but I have not been about able to boot Win98 on it.

Edited March 2 by awkduck