Drew Hoffman

Thank you for testing. That is certainly strange behavior, the only way I think that would be able to work is if my driver is loading first, sets up communication to the codecs, configures the codec at address 0 to start receiving from stream 1, then is unloaded. Then the Watler's driver loads later, sets up the controller a second time, doesn't send any messages to codec 0 and just starts streaming audio to stream 1 which happens to go to the right place. Can you tell me what chipset / PCH that netbook is using as well as the PID and VID of the HDA controller ? It's becoming clear that I'm missing a lot of newer Intel chipsets that should have the nosnoop flag set and I should probably send a pull request to Sbemul and VSBHDA once I know everything that's missing. I haven't been able to do much coding lately as I have been ill and screens are still giving me headaches.

I'm setting the PCI config flags based on vendor and device ID, and 8d20 is currently in the list while 10F0 isn't. The white list from mpxplay probably wasn't updated for 10 years. Need to find the most up to date version of that list of device IDs. Snd-HDA-Intel doesn't seem to use that approach anymore. Alternatively I should set nosnoop on all unknown Intel device IDs and only enumerate the devices that don't need it (ICH 8 and 9 and what else?), and also add a registry config option to force it on or off. Unlike Microsoft I only need the driver to function on x86, if someone is dedicated enough to get it working for Win2k on Alpha I'm not really sure what hardware exists to use it on. Video cards with HDMI audio that won't have drivers anyway and maybe one Terratec pro audio card? I did manage to find an official description of the caching policies of the UAA driver: https://learn.microsoft.com/en-us/windows-hardware/drivers/audio/data-copying-and-caching-policy Just don't know a good way to get the audio buffer to be MmWriteCombined on Win98 while still using PortCls WaveCyclic. Could add an extra bounce buffer and do a third buffer copy? Could also discard the whole framework of PortCls and write a Stream driver instead which would save a buffer copy anyway, or make a VxD driver, or fix Watlers?

Byte 0x42 bit 1 of config space (0x02 mask) is the Snoop flag for the ATI/AMD SB450/SB600. I am only setting that bit on those models currently, which are PID 0x437b and 0x4383, but yes I may need to do that for newer AMD chipsets as well. Looks like Mpxplay sets it for several other PCI IDs. You can test with WPCREdit if toggling that bit gives you better results. If you don't know which PCI device is the HD audio controller, it's the one with class 04 subclass 03. I should copy that entire list of PCI Config Quirks from mpxplay or the modern Linux snd-hda-intel. I had originally copied the few that were in the HDA.pas source code of Watler's driver but that list is clearly incomplete. I don't know if the Microsoft KB888111 bus driver sets all the snoop config bits (if it's marking the buffer in MTRRs? as non cacheable it doesn't have to?) but the HDA bus driver that's about to be merged into ReactOS sure does: https://github.com/coolstar/sklhdaudbus/blob/cf88f2020c836978660f3378917b0dd3274570c9/sklhdaudbus/fdo.cpp#L574 This allocates the audio buffer through MmAllocatePagesForMDL which will return non contiguous physical pages with no control over the cacheability. Also there still seem to be occasional race-condition bugs with stopping and then quickly starting streams on both VMware and real hardware. When changing tracks in Winamp 2.95 it may play silence or choppy like the r/w pointers have gotten out of sync and lapped each other. Sometimes the first system sound after stopping music will have a blip of music mixed in, sometimes the short click navigation sound is lost entirely on VMware but this seems to be better on real hardware.

So maybe a driver that only does Adlib emulation would be better to create? It's just that SBEMUL is a SYS driver not a VxD (and i think it has to be, because it's acting as a kernel streaming filter driver) but it's using the ASM interface to VMM to install the IO handlers. The alpha of VDMSound does the same port-trapping but for its own SB16 and Adlib emulation and all written as a VxD. I guess there is no other interface to the VDM on 9x? I don't have much experience or knowledge of x86 assembly.

@deomsh does your universal hdaicout.hda file work for any IDT and VIA HD Audio codecs or only Realtek? I'm looking for hints on what verbs I might be missing for my native WDM HD Audio driver which now works on most Intel chipsets with a Realtek codec but is still silent on IDT and VIA codecs . Unlike the Watler's driver I have a codec node parser if a very basic one taken from a hobbyist OS. https://msfn.org/board/topic/187713-native-wdm-hd-audio-driver-for-windows-98seme/page/1/

I don't have any Intel 10th Gen systems immediately available to test on and there are still similar issues with some AMD chipsets as well both older and newer. Right now I am focused on refactoring to allow support for multiple codecs on a link which is required to support laptop docking stations and HDMI display audio. @SweetLow you did some research on the SBEMUL.SYS driver a year ago and patched it to allow the SB16 over the low DMA channel. Did you decompile the whole thing or just reverse engineer the registry settings? Since it already traps the port for Adlib FM do you think it would be possible to route the command & data port writes to the DOSBox or Nuked OPL emulator? I have tried putting that driver into Ghidra but couldn't make much sense of the int 20 hooks and couldn't load symbols for PortCls and KS in SYM format so I didn't get very far.

Which system are you still having the looping problem on? Is it the Nvidia MCP78 or the Sunrise Point PCH or something else? The DXDiag test failure seems to be due to restricting the available sound data formats to 22050 hz or greater (and only happens on my VM with DirectX 6.1, it does not happen with DirectX 9 either way). I will undo this change in the next release and fix the issue of 8-11khz WAV sounds crackling properly, by creating smaller buffers.

The current documentation for AllocateCommonBuffer specifically says that the bCacheEnabled parameter is ignored and to use AllocateCommonBufferEx instead (not supported until Windows 8). The Windows 2000 DDK documentation doesn't say that (it just says "CacheEnabled :Specifies whether the allocated memory can be cached. ") but it might still be the case. I set it FALSE anyway for the CORB, RIRB, BDL, and DMA position buffer. The audio buffer is not allocated through AllocateCommonBuffer anyway though, it is allocated through DmaChannel->AllocateBuffer which is a function from Portcls. KeFlushIoBuffers is #define 'd to nothing in the Win2K DDK version of wdm.h and the __wbinvd() intrinsic is not there yet either. As long as it works on Intel controllers with the no-snoop flag set I am not going to overly worry about this, but the same issue might also occur on the ATI/AMD SB450/SB600 and there it might not be possible to turn the snoop bit on if the BIOS leaves it off. Need to check that again with WPCREDIT.

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 Released Alpha-016 https://github.com/andrew-hoffman/WDMHDA/releases

Have not been able to test much on real hardware lately since I'm not at home. I feel like it's got to be 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.

My driver is is a mini-driver using the WaveCyclic miniport. ReactOS already includes Dogbert1's CMI8738 driver which works on the same miniport, though they have modified how it builds (compared to the version in the Google Code Archive) to remove the dependency on the Microsoft DDK. I would bet that CMI driver was also based heavily on DDK sample code just because the file and function layout is very similar to the two examples but I can't prove that and wouldn't want to accuse anyone of anything.

The Dell Mini 9 seems to have a USB keyboard and track pad, the Acer Aspire N450 netbook has a PS/2 Keyboard but USB Track pad, the Latitude E6400 has both ps/2 keyboard and track pad which is good since I can't get the USB controller drivers to install on that. Also my driver is still not producing any sound from IDT codecs it seems. That's all the old laptops with HDA I had immediately available. On another topic, does anyone have tips on getting a driver to build without the official Microsoft DDK? I probably shouldn't be redistributing the full sample code and headers, even if Microsoft themselves have uploaded newer DDKs to Github under more permissive licenses.

Fixed the page fault crash and the hang on Atom systems. https://github.com/andrew-hoffman/WDMHDA/releases/tag/Alpha-014-1 The problem I'm having installing Win98se without QuickInstall on newer hardware is not the resources crash that SweetLow mentioned and running JHRobotics' Patcher9x does not fix it. I think it is an ACPI related issue with Configmg as installing with setup /p I will allow me to at least boot in to the OS after setup, but it seems to do so in a fallback mode where no PCI devices are detected or enumerated and that is not very useful for testing a PCI device driver. I get somewhat better results copying an image of an existing install, after including the new ICH8+ machine.inf files and NUSB. As long as the machine has PS/2 ports anyway. If it's a laptop I end up with the Catch-22 of needing to install the USB drivers and being unable to click Next on the dialog box.

OK I think I figured out that problem. It's a page fault, I'm zeroing some memory that doesn't need to be zeroed. Will fix today.

Released Alpha-014 which ignores outputs marked as not connected by the BIOS pin configuration. https://github.com/andrew-hoffman/WDMHDA/releases/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?