MisutaaUrufu

I meant "quirks" as in the behavior was odd and unexpected; I didn't mean it in the technical sense, my apologies. I didn't try mplayer, no, but considering you mention that none of them gave sound through DOS in Virtual Box, I imagine the same would go here as well. That is the correct codec, as far as I can tell.. Vendor ID 1AB8 is identified as Parallels Desktop, and their other simulated hardware devices follow a similar convention. Likewise, changing the codec value gets reset on next boot by the TSR anyhow (it's blocked out with Fs before the driver is loaded by Windows). There is no "modem" attached to the virtual machine; only a simulated PCIe ethernet card (a Realtek model). The parallels log file for the virtual machine indicates that the HDA device is being activated, but that the VM is making an invalid read at an incorrect address. — If I let it run for too long it'll actually build up a hefty log file just filled with the "invalid read" lines. (It reached 9GB at one point. 9GB of just that one line.) — I'm thinking this may be concerned with HDAICOUT and the widget addresses in HDA configuration. The odd thing is the number output in the INI by HDAUtil for the Subsystem ID is different than the one populated in the HDA configuration by the TSR. But changing it has no effect as the TSR resets the value on boot. I can do you one better. Seeing as the download page had to be accessed in convoluted fashion via the wayback machine on the internet archive, I took the liberty of uploading the installer directly to the archive itself for ease of access: Microsoft High Definition Audio Utility 64-bit : Internet Archive You seem to know a lot more than I do on this particular topic though. I will try removing the network card from the VM and see if that has any effect later on, but I highly doubt that will change anything. Unfortunately AC'97 support no longer works in Windows 95 on Parallels. They deprecated support for "legacy" systems a few years back, so whilst the VM does simulate an AC'97, it's behavior has changed from how it worked when Windows 95 was an actively supported configuration. They no longer provide sound drivers either (only video). I've tried numerous generic drivers with no luck; they install, and Windows says they work, but no sound is passed to the main OS, and the parallels log just spits out "[pcm_out] reset inside DMA" every once in a while if audio is "playing" in the VM. — This log output is infrequent, compared to the HDA log output. This is why I am trying to get the HDA2.dll driver working in the first place. AC'97 support is broken, but I at the very least can confirm that some sort of interaction with the HDA controller is happening (the soft crackle through earbuds/headphones when audio attempts to play). In theory, if I could get the configuration correct, I could get audio out. However, it is sounding as if I may need an entirely custom configuration to communicate with Parallels' implementation of HD Audio. Off topic: Ironically, Parallels provides an OS/2 driver for sound. It's just Windows 2000 and earlier they don't provide.

Parallels Desktop App Store 1.5.0 (Roughly equivalent to version 15 or 16). — VM is configured as a generic Windows VM rather than a 95 VM (as 95 VM support is deprecated and official audio support no longer exists; Generic Windows Machines allow use of the Intel HD Audio device.) There is, and the memory address is F0140000 with no IRQ-conflict. More notes: Attempted running without HDAICOUT.HDA, as well as with the generic copies hosted here. No luck. Similar to others, codec values in HDACFG.ini are different before and after Windows boots. Mine are all $FFFFFFFF. Setting Verbinterface to $0 prevents the desktop and taskbar from displaying; Windows hangs at my wallpaper, requiring a forced reboot. Changing the timing values to 250+, and setting the pcipatchB to various values, so far, has not worked. Attached are the codec files exported by Microsoft HD Audio Utility (x64) from Windows 10, in INI & XML format. HDALog contains various entries that are all 0s, though roughly 50% of entries have non-zero values. Update: Attempts to play audio directly in Media Player returns that all audio devices are in use. HDA_Codec.ini HDA_Codec.xml

Hey, sorry if I seem unintelligible on this topic; Drivers & Audio are out of my wheelhouse when it comes to computers, but would anyone here know how to go about getting the HDA driver working in 95 OSR2.5 in Parallels for Mac? — Parallels for Mac doesn't offer support for audio on deprecated systems, but I can set the VM to a "generic" Windows OS, which provides Intel HD Audio support. However, I've been pouring over forums and different config steps, and I'm not really sure what to do. The chipset presented by Parallels is the Intel ICH10 with Intel HD Audio, Vendor ID 8086 & Device ID 293E, which are correctly detected by the driver when installed (I verified this by comparing it to a Windows 10 VM's DID & VID). However, beyond that sound doesn't work, neither in DOS mode nor in Windows. Both act like it works, but with "quirks"; DOS mode will just be like "yeah sound is playing" when I tried test utilities from another form thread on the driver, whereas in Windows, the media player and the system sounds window will get "stuck" in a playing state, but the progress scrubber will not move (in media player) and it must be "stopped" manually. — But there's no sound at all when this happens. Method of install: HDATSR -> AUTOEXEC.BAT Custom INF installed for the PCI card. HDA Sound as default output device. Min & max virtual cache set to low 'wave=hda2.dll' in System.ini I've tried various adjustments, deleting HDAICOUT.HDA (after backing it up of course), changing values in HDAcfg. I'm not sure if there's something I'm missing, if ICH10 is too new for this driver, or if Windows 95 has a weird quirk (everywhere I've read it seems like people have tried this with Windows 3.1 or Windows 98SE, and have assumed it will work with 95 as a result.). Here's my HDAcfg, for reference: [ALLHDA] $00FC=$293E8086 [HDA] TSR=TSR FOUND PCI_VID=$8086 PCI_DID=$293E [BUSMASTER] myPCIHI=$0012 myPCILO=$1000 aPCIHI=$0011 aPCILO=$1000 aPCI=$00111000 [HDA_293E8086,04001AB8] cardmemoryregistersLO=$0000 cardmemoryregistersHI=$F014 Mytimer=1 Verbinterface=$1 wait1=$100 wait2=$100 pcipatchB=$0000 PCI_BUS=$00 PCI_DEVICE=$1F PCI_FUNCTION=$0 GCAP=$2201 VMIN=$00 VMAJ=$01 GCTL=$0001 CODEC BITMAP=00000001 CODEC Index=$0 CODEC_VID=$1AB8 CODEC_DID=$0001 CODEC_REV=$100100 CODEC_NODEINFO=$010001 CODEC_AFG_GPIO_CAP=$C0000004 CODEC_AFG_SUBSYSTEM_ID=$1AB80101 CODEC_AFG_PM_SUPPORT=$0F CODEC_AFG_PCM_DEFINITION=$1E07FF CODEC_AFG_F000B=$01 SleepingWidget=$02 VolumeWidget=$14 OutputWidget=$02 Note that most of these values reset on reboot; only the widget values can persist. What is above is a "stock" config (I deleted the one i modified and let HDATSR rebuild the config, and these are the values it presented). Another note is that I was going to try the Microsoft HD Audio Utility to try and compare the data between Windows 10 and the HDA configuration file, but I only have access to 64-bit copies of Windows outside of 95, and the only version shared online is the 32-bit version, which refuses to install on 64-bit systems (it will say to download the 64 bit inversion instead). I was able to find an archived version of the 64bit installer of HDAUtil via a url punched into wayback from the extracted contents of the 32bit MSI. I have HDAUtil if this helps. Would anyone be able to point me in the direction of troubleshooting here? Like I said, this falls out of my area of expertise.