deomsh

@DAVE-H: Thanks. As far I can see only four lines in HDAICOUT.HDA are needed for your Supermicro X7DAL-E+ server board. My assumption is that Pin widget 014 is hardwired to your Output Jack (according the data sheet that should be 'normal', but Motherboard manufacturers sometimes have other idea's). ------------------------------------------------------------------------------------------------ HDAICOUT.HDA ------------------------------------------------------------------------------------------------ Begin $2017FF00; CODEC RESET Function group 2 $2017FF00; CODEC RESET DOUBLE ! $21470740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $2143B000;AC_VERB_SET_AMP_GAIN_MUTE;unmute_output End ------------------------------------------------------------------------------------------------ This version of HDAICOUT.HDA will ONLY work with following settings in HDACFG.INI: OutputWidget=$02 and VolumeWidget=$0C. They should be already there in your HDACFG.INI. Maintaining SleepingWidget=$02 will do no harm. For convenience I attach above HDAICOUT.HDA as version 201, including a small Easter Egg. You will find it if you read the last part of the file. Dave-H_ALC883_Hdaicout.hda.201 BTW: this version is NOT designed for all possible ALC883 codec implementations!

I didn't talk about direct access, but about using a webproxy. I used http://proxycrime.com to have at least a sort of access. Good rendering is a different issue, although Opera has always User mode as ultimate remedium.

@Dave-H: Thanks for testing. Any difference with your Sound Mapper? Less "pops" is an interesting observation, I will try on my ALC662 system. BTW: please attach HDAICIN.TXT after booting my last version of HDAICOUT.HDA, so I can see which Verbs of the almost 200 Verbs are truly needed.

@Dave-H: I finished the Realtek ALC883 HDAICOUT.HDA. If you'de like to test: rename your working version to HDAICOUT.OKE , rename the new file to HDAICOUT.HDA , copy to your %windir% and reboot. Please attach HDAICIN.TXT Dave-H_ALC883_Hdaicout.hda.200

@UCyborg: Thanks a lot. At first sight STAC9921 seems to be fully implemented in Virtualbox. Is it possible to attach the saved xml, so a can take a closer look? Mine is 389KB (File -> Save Working Codec as -> STAC9921.xml). Did you test Mpxplay is pure MS-DOS?

@Dave-h: I think you're right about activate.exe, maybe the name of a file with same funtion in one of Watler's other Audio drivers. But I don't know for sure. It doesn't seems important to me. Watler explicit mentioned HDARUN.EXE if a Multimedia Timer is needed, as in Win3.x Standard mode. Don't use HDARUN in Win9.x if possible, can give really bad crashes. That's my concern because you first had to use it as a sort of "Lender of last resort". HDARUN must be started manually after each startup, you will be aware if you are using it.

Of course Siria is right, but luckily the situation is much better on Windows 3.1 browsers with a webproxy as workaround. Although I must admit that IE2.0 didn't work and with IE5.0 downloads are not possible. Just checked situation with Opera 12.02 on Windows 98se:

@Dave-H: Thanks for your kind words, but without your patience and perseverance there would have been no success, although we are not finished yet in my opinion. You still didn't tell if you can play Digital Audio without HDARUN (so Mytimer=1). Also I am still working on a ALC883 version of HDAICOUT.HDA i'de like to have tested. About files: you need to save HDA2.DLL, OEMSETUP.INF, HDATSR.EXE, WAVEOUT.EXE, HDARUN.EXE (indeed in folder activate), the README's and for more convenient install my GENHDA16.INF. Further for your system working versions of HDACFG.INI and HDAICOUT.HDA of cause.

@dencorso: Thanks. Don't forget Watler made the Win3.x driver! I did only some minor things.

@Dave-H: Only WAVEOUT.EXE is needed, other files are the source code (16-bits Delphi). I don't know how @ABCDEFG made his picture, but your observations are right, only first two digits of four are changed by moving a slider of WAVEOUT. Actually there are 255 steps of 256. Your codec's Volume Widget has only 127 steps (7F in Verb 20C3B07F). No idea what the box is ment for you marked with an arrow. Only "0" ist working. It is sad there is no possibility to direct WAVEOUT directly to different Volume Widgets. I wrote once a HDAICOUT.HDA to listen Analog Audio CD, redirected through the codec to my Output Pin Widget. I only could use AHDA17O to set the Audio CD volume by sending appropiate Verbs, for Digital Audio I could use the Volume Control of - say - Mediaplayer. Luckily my headphone has Volume Control.

@Dave-H: Good news. About the PCM-values: @ABCDEFG is right. You can check HDACFG.INI. After changing one slider of WAVEOUT the PCM-value will be updated in HDACFG.INI (definitely after clicking the Button). There is no need to edit the value. Last volume setting is saved, should be still there after reboot. Please check on your system. Delays and pops: fully normal. You are still using a (modified) 'universal' HDAICOUT.HDA. I am working on an ALC883-version. The file will be ready in a few days. Some Verbs I want to use are a bit complex. Are you still using HDARUN with Mytimer=0, or is Mytimer=1 working too? Sound quality should be a better without use of HDARUN.

@Dave-H: Yes. According to the ALC883 data sheet 0C should be the Volume Widget all jack's are connected to. Please check if one of the other jack's of your back-panel gives sound, just for testing purposes. Is PCM=$FFFFFFFF in HDACFG.INI? Did you try WAVEOUT.EXE? It's included in HDADRV9j.7z. If you click the waveOutGetDevs-button you should see the same as in my picture in the post I mentioned. I was just testing the Volume Widget of my ALC662 codec: mine is according to the data sheet, is working with WAVEOUT and is independent of settings in HDAICOUT.HDA. Try playing a MP3 with Windows' standard mediaplayer too, and check if the volume slider is working.

@Dave-H: did you set VolumeWidget=$0C ? Further: please read my post of april, 2 (answer to UCyborg).

@Dave-H: my congratulations with your HDA sound, you deserve it. Regarding sound quality: did you try Mytimer=1 in HDACFG.INI, so without HDARUN?

@Dave-H: Please try again with new version Dave-H_Hdaicout.hda.200

@Dave-H: I am sorry to hear you don't possess such a card. Nevermind, was just an idea to test if your Sound Mapper is working. Same for the four files I ment. 98 SFC will test the three original one's too for integrity. Just to be certain your installation is valid, but it's up to you. I have a new HDAICOUT.HDA version to test. Please rename your first one to HDAICOUT.HDA.000 and rename te new one to HDAICOUT.HDA. Afterwards please attach HDAICIN.TXT and HDALOG.TXT again. This version is mainly to test if the Verb Interface is fully functional and if Play-related functions of your codec are set correctly.

@Dave-H: The files resides in WIN98_32.CAB and WIN98_43.CAB. If checking is a difficult, you can use System File Checker (Run -> SFC). Watch the settings. Best is: let SFC do a first run and choose everywhere "ignore". If you want to restore original files, let SFC make a backup.

@Dave-H: Thanks for the file information. I assume that "checked" means also the files are binary identical with the files from your WIN98se CD. I am searching for some spare time to work at step: Check if the CODEC is fully programmable according to the data sheet. I will have to write HDAICOUT.HDA adjusted for your chipset. I'd like to see to log-files that should reside in your WinDir: HDALOG.TXT and HDAICIN.TXT. If they exist, will you be so kind to attach them? BTW: about your Sound Mapper problems: do they disappear with a normal PCI sound card, while HDA2.DLL is disabled? Disable is very easy: with semicolon before the wave-entry in SYSTEM.INI [Drivers] ;;wavehda=HDA2.DLL.

@UCyborg: I didn't ment to offend you. I am not an expert either, I only tried to say that using "facts" from experiences with other drivers like AC'97 doesn't say anything to me. You didn't answer my question if you could give the HDA controller an EXCLUSIVE IRQ. If that's possible on your system and you have still choppy audio, I would tend to agree that IRQ's are not a (possible) problem. Interesting that with Windows XP as a Guest in VirtualBox HD-audio is not possible, so your Windows 95 OSR2 with a Win3.x driver is already surpassing Windows XP! The (older) posts I red where from angry Win2k/XP users about not working HDA, in Windows 10 the problems where about choppy audio. Windows 7 was not mentioned, but I didn't do a full search yet (very time consuming). But I am becoming more interested in VirtualBox, if I have some spare time I will try an installation on my Windows 10 as a Host. But in the mean time I give Dave-H priority if you don't mind, it's his thread. It would of interest too try MS-DOS HDA players, like I suggested Dave-H, but with respect to choppy audio. About volume setting for your virtual STAC9921 codec: I have red somewhere that it's not fully implemented in VirtualBox. If you have some spare time I'd like to see the codec graph. My ALC662 looks like this one: You can produce this graph with a Microsoft tool: High Definition Audio Utility 3.3. It needs Windows 7 or higher. If I understood well, you are running Windows 7 as a guest too. https://en.freedownloadmanager.org/Windows-PC/Microsoft-High-Definition-Audio-Utility-FREE.html After installing the msi, go to File -> Local Machine Codecs and load DEV9221 or something like that.

@Dave-H: Thanks for testing, after the BIOS option I do not see means to do something with the HDA-controller. In the Intel High Definition Audio Specification I found that the HDA controller is opaque for responses from the CODEC. In my (maybe simplified) understanding that means that rewriting HDAICOUT will have no influence on the HDA-controller. IF the controller is the real problem. Regarding Sound Mapper, did you check following with your Win98se CD: MMSYSTEM.DLL, WINMM.DLL, MSACM.DLL, MSACM.DRV and MSACM32.DLL. Check your Registry for Wavemapper too. This is my (dutch) Sound Mapper Reg-entry in HKCU (same in HKU): [HKEY_CURRENT_USER\Software\Microsoft\Multimedia\Sound Mapper] "Playback"="HDA Sound " "Record"="" "PreferredOnly"=dword:00000001 "UserPlayback"="HDA Sound " "UserRecord"="Geen opnameapparaten"

@Dave-H: MPlayer will not work in a DOSBOX, because inside it cannot connect to the real hardware. To move on we have to solve a few problems. 1) Not hearing soft "plops" or "clicks" during boot. 2) Not having Slider movement while playing an audio-file. 3) Check if the CODEC is fully programmable according to the data sheet. 4) Write a CODEC-specific HDAICOUT.HDA and test it. Although I have a certain order in mind, I used bullets in my previous post, because I am still not fully sure that there is NO relation between the way a CODEC is programmed by HDAICOUT.HDA and sending some "device ready" message to the driver. My actual understanding is that they are independent and that such messages are sent/ received by the HDA controller in relation to both the CODEC and the driver. In that case concentrating on 3) and 4) will be a waste of time. In many CODECS all, or almost all, Widgets that connect to Jacks, are in the default state set as Input devices. Drivers from ALSA, FreeBSD or Kolibri are using Widget parsers, asking all information (including all connections) from an unknown CODEC with so called "GET VERBS". By sending "SET VERBS" CODECS can be programmed. You can even redirect analog inputs like MIC and CD to analog outputs and mix then with digital audio. HDA2.DLL doesn't have a real Widget Parser onboard, but is using the settings of HDAICOUT.HDA. By absence of this file, some settings are set to a default value (at least the last three lines of HDACFG.INI). All these "new" settings are reset to defaults by the BIOS during reboot. You don't have to worry about your triple-boot companions. I asked you earlier to test Jacks, just in case there is a problem with my version of HDAICOUT.HDA in relation to your specific CODEC. That will be the case if you're hearing soft "plops" or "clicks" during boot on other Jacks. So each jack has to be tested with one boot seqeunce. That's all, regarding first bullet. With PCI related BIOS settings I didn't ment Audio settings. According to the manual of X7DAL-E+ disabling audio is done by a jumper. But in your BIOS setup there is on page 4-9 ONE entrance that can be tested: Enable "Emulated IRQ Solutions", default is Disabled. This option is ment for legacy systems. My (bit loose) idea to try this is because audio problems sometimes can be "healed" by disabling MSI (according to some Linux forum post's). Its difficult to find more information about this BIOS option, but I think it's worth a try (although first backup all your configuration files to be for sure, and better reset first to default when booting in your other OS). In my opinion there is real progress if the Slider of an audio player is moving with this BIOS setting enabled. Maybe other members can give some input about this BIOS option. Before investing time in a CODEC-specific HDAICOUT.HDA I have to know if GET and SET verbs are fully functional, can be done with AHDA17O, or by another (less general) version of HDAICOUT.HDA.

@Dave-H: You're right, no difference. So there is no need trying "pcipatchB" settings in HDACFG.INI. At least it seems that these registers of your HDA-controller are not the problem. Summarizing you have following problems/ did following tests/ took following actions/ gained following results: Trying to install HDA2.DLL -> PASSED Try to hear "something" with the default settings: NOT PASSED Try to hear "something" with experimental general version of HDAICOUT.HDA: NOT PASSED Try to select "HDA Sound" as Preferred Playback device: NOT PASSED Try to hear "something" while using different Verb Interface: NOT PASSED Try resolving conflicts in System (conflicts between Motherboard resources System timer/ DMA controller): NOT PASSED Try to hear "something" with different "Mytimer setting" in combination with HDARUN: NOT PASSED Movement of the Slider of Sound recorder while playing a WAV-file: NOT PASSED Try to hear "something" without using HDATSR and setting [BUSMASTER] to memory addresses "out of the reach of Windows": NOT PASSED Try to hear "something" with different "wait" settings: NOT PASSED Compatibility of actual HDA PCI-Registers with settings of working HDA-player: PASSED If you like to move on, I see only the following possibilities where I can be of use: Try to hear "something" trying ALL audio jack's Change PCI settings of your Motherboard's BIOS Check communication with the CODEC with help of AHDA17O Write specific HDAICOUT.HDA for ALC883

@Dave-H Great, you deserved it. Nice picture, but I need another one. Please try this batch-file, assuming MPLAYER resides in C:\MPLAYER together with a WAV-file, not a short one, say 60-100 seconds. Rename it to YOUR.WAV, or edit the batch-file according to the name of your WAV-file. Make following batch-file and save it in C:\ as BUG2.BAT. ======================= BUG2.BAT ======================= cd MPLAYER MPLAYER YOUR.WAV C: cd \ WIN ======================= BTW: if needed earlier, edit the command-line. Afterwards the batch-file will boot DIRECTLY (no reboot) into Windows. If the player won't stop, try [ESC]. Once in Windows please do the same as you did earlier to deliver a picture with AHDA17O. Details are in my post of monday 10:01 pm.

I didn't either at first sight. Yes, same folder.

@Dave-H: Sorry, forgot they are not included, tonight I just checked the files, they where exactly the same as allready on my System (my smartphone is not compatible with Win9x). Good you are carefull, but it's safe. Read: https://en.m.wikipedia.org/wiki/CWSDPMI BTW: you used CWSDPMI.EXE with Judas 2.1c allready.