onethirdxcubed wrote on 2026-01-22, 23:32:

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.

I can definitely negate this. The Device Manager sais that APM 1.2 is installed on the MSI B85M-E45, but is has a yellow exclamation mark because of missing drivers.

Cant it be forced to 5/7 in the driver?

Do you mean the IRQ? It's 5 already.

ElTentakel wrote on 2026-01-24, 13:35:

Do you mean the IRQ? It's 5 already.

bakemono wrote on 2026-01-22, 02:11:

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.

Yes, i've read it but I dont't understand what you want to point at, because the assumption, that the IRQ is 16 or 36 is not correct for that specific mainboard. It just reports APM (and even shows the shutdown screen) and has IRQ5 for the HDA device by default. I'm not even able to change it.

Just for info: The soundblaster Live! works perfectly on this board, so I assume the IRQ handling works relatively well.

I have two different board from the C2D era here, I could test them, too.

No idea. Just taking it at face value.

P5KPL-AM EPU, ACPI 2.0/APIC disabled in Bios. But since it powers down, i assume ACPI 1.x? Windows can't see any devices caused by missing System bus drivers.

IRQ 11, fixed, shared with other devices (QuadroFX 1300, USB Host)

Driver installs and starts fine, but no sound at all.

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

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.

I did this on the D3003, but DgbView gives me no output. The system just freezes. I tried the same with die HDMI part, but that one gave me the info, that it couldn't find any outputs.

I released an Alpha 015 that tries to use the DMA position buffer but it seems that doesn't work right either (it just times out and falls back to using the LPIB) and also the Gigabyte C1037UN system won't get in to Windows with any USB devices plugged in. That's not caused by my driver since it's still broken with my driver completely uninstalled, but it might be caused by the SoftGPU VGA driver since it'll start in Safe Mode with legacy USB. I can plug in USB devices after boot and they will function. Maybe I just need to reinstall everything yet again.

I have this issue all the time with nusb installed on different systems.

Got things working on Intel PCH platforms! The problem wasn't IRQs at all, it was the HD Audio Controller's PCIe transactions no-snoop bit which wasn't getting properly cleared because of a typo in a type-cast (dereferencing it twice ).

With no-snoop enabled, what happens is the audio data is written to CPU cache but not flushed out to main memory unless there is some other activity going on to use the cache and invalidate those pages (like Scandisk). I'm not sure if there is a way to explicitly flush the audio buffer to main memory or some flags to AllocateCommonBuffer which I should be passing but aren't. KeFlushIoBuffers is defined as nothing and the Windows documentation says the cacheable parameter is ignored in AllocateCommonBuffer.

Released version Alpha-016: https://github.com/andrew-hoffman/WDMHDA/releases

• Fixed PCIe No-Snoop flag which was causing garbled audio on Intel PCH and newer
• May be fixed for AMD SB450/600 as well, need to test
• Fixed DMA Position Buffer but disabled it by default again

Note: DXDIAG Sound test is broken on this version, it reports Success immediately without actually playing anything. I need to expose supported audio formats at rates lower than 22khz for this to work properly

I tested Version 016 with the ALC887 on the MSI B85M-E45 again and it works perfectly. Even DirectSound games like NFS V work. These are really great news, a big thank you!

What doesn't work however is Sbemul and Midi Emulation for Dos. But this is expected, because these drivers are designed for Windows XP?

ElTentakel wrote on 2026-01-29, 18:41:

I tested Version 016 with the ALC887 on the MSI B85M-E45 again and it works perfectly. Even DirectSound games like NFS V work. These are really great news, a big thank you!

What doesn't work however is Sbemul and Midi Emulation for Dos. But this is expected, because these drivers are designed for Windows XP?

SBEMUL and MIDI Emulation for DOS should be working, actually, and it functions on many of my test systems, but that driver is fragile and very opaque about what it's doing. It will silently disable itself if BLASTER is already defined or if there is another device using IRQ 5 DMA 1 or there are some Registry settings it doesn't like and for other reasons I don't understand yet. Someone needs to decompile that driver and look at it properly. I tried with Ghidra and didn't get very far and there are no debug symbols available and not much documentation.

Even in Intel's boasts about how SBEMUL made legacy DOS support unnecessary they only claimed 60% compatibility.

You could try the VDMSound Alpha release for 98se but I haven't been able to get that working myself.

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.

Still the case with 016. it shares the IRQ11 with the GPU. Also something crashes after driver installation because of an illigal access. Despite that, I tried SBEMUL and Midi emulation and both do work, with distorted sound.

Nothing was changed for AMD chipsets for this version, only a caching flag for Intel. The same garbled/looping sound issue is still present on my thin client with AMD SB600 in alpha-016. I also still don't have any audio with IDT, Analog Devices and VIA codecs.

Now that I know the looping bug is likely a cache coherency problem and not an IRQ bug it should be easier to track down what is going wrong there.
I need to investigate what the Linux, Watler's and Mpxplay drivers do for these chipsets. Maybe there is a similar flag or maybe it can't be changed and PortCls must be subclassed in order to allocate the audio buffer in a different way to make it uncacheable, or explicitly flush the caches with WBINVD on every buffer write. (this is not a good choice as flushing all caches 100 times a second will severely hurt performance).

Hi... This is fantastic, it's exactly what I was looking for for my PC, and I hope it will be possible to emulate DOS games within Windows with MIDI sound!!!

I found a hint in "Oney Programming the Microsoft Driver Model 1999", and there is stated:

You'll call AllocateAdapterChannel. It will call your adapter control routine, which will call KeFlushIoBuffers if you allocate […]
Show full quote

You'll call AllocateAdapterChannel. It
will call your adapter control routine, which will call KeFlushIoBuffers if you allocated
a cacheable buffer and then call MapTransfer. Your DPC routine will call
FlushAdapterBuffers and FreeAdapterChannel. In all of these calls, you'll specify the
common buffer's MDL instead of the one that accompanied the read or write IRP
you're processing

I just pointing that out, because "MapTransfer" is missing in your driver and is also labed as obsolete with Windows XP. So I assume they wouldn't use it in an example anymore.

Yes I have that book, and the second edition, and the code samples too. In this case we are doing "Bus-Master DMA with a Common Buffer" and don't need MapTransfer. We always keep a consistent audio buffer and aren't mapping chunks of audio from user space in and out as more buffer is played, it's all copied by PortCls into the one buffer. Your comment would be relevant for the NVMe9x driver.

Ah ok, I understand. i'm coming from an Embedded / Linux / Bare Meral world, so don't blame me for stupid assumtions ^^.

I found a different hint on a dev forum:

"What about AMD architecture, where there is no snooping but a coherency protocol that runs above Hyper-Transport?
PCIe “no-snoop” is translated into an HT “coherent” bit, which presumable generated HT transactions to make sure that the data is not cached in one of the CPUs"

https://community.osr.com/t/allocating-non-ca … for-dma/30188/7

Which seems to be exactly what you have told. I wouldn't expect that difference in the same architectural world.

/edit: tested the driver with disabled L1 Cache and it works. However, the system is unusable slow as expected.

Many thanks to your driver! It works on my 2020 Thinkpad P14s Gen 1 using your latest WDMHDA Alpha-016.

Video of your sound driver working very well even when using 3DMark2000 https://www.youtube.com/watch?v=XSiYbmkA-gw
Documentation of that laptop: https://github.com/yeokm1/retro-configs/tree/ … thinkpad-p14sg1