deomsh

I tested this too lately, a no-go indeed. In 'Virtual Box 7' I tried changes on-the-fly in HDAICOUT.HDA, doesn't work either. So AFTER codec initialization it seems HDAICOUT.HDA is not used anymore. But I noticed something about the volume SET verbs in HDAICOUT.HDA which can be of importance: in the case of VBox' (virtual) HDA-codec my 'new' volume settings with SET verbs '$XYY3B01F;AC_VERB_SET_AMP_GAIN_MUTE;max_vol;R+L' are far too low. Even with max volume on the Host I barely could hear Windows' Startup Sound. So maybe I should make variations with max_vol's 7F, respective 3F and 1F. BTW with HDA2.DLL version 9L, HDAICOUT.HDA will be less needed IF 'widget types' are correctly identified (I observed 'identifying widgets' in HDALOG.TXT on 'Virtual Box 7', with sending appropriate SET verbs too). The Digital Beep can be used, but must be activated with a special SET verb AND 'guided' to the output of choice. But still a HDA-driver needed, which SPEAK.EXE isn't. Interesting, I have red this setting can speed up disks with 10%. But don't forget KB139669: https://web.archive.org/web/20090827171449/http://support.microsoft.com/kb/139669 BTW I am very happy with your 'tip' using 'Yamaha S-YXG100plus soft synth' as midi device together with VDMSound. Works great with 'Prince of Persia 1', on my (VBox 7) system only IF Windows' Startup Sound is NOT disturbed - sadly this is not always the case. But I passed Level 9 already - again, after 20 years.

Thanks, 'HD Audio whisperer' sounds nice! About your HDAICOUT.HDA, seen the response values of the GET verbs, not all lines are needed. Less lines is better. BTW this is a 'weak' aspect of any universal HDAICOUT.HDA, although users can make their own version by commenting lines out one-by-one. Only max about 180 reboot's needed. Next version of HDAICOUT.HDA should be your final one, if I see things right (don't forget: from my point of view it's all 'pure theory', I don't even have access to a laptop to do tests with speakers etc.): Begin $0053B03F;AC_VERB_SET_AMP_GAIN_MUTE;max_vol;R+L;AD1981HD-speaker $00570C02;AC_VERB_SET_EAPD_BTLENABLE;ExternalAmplifierPowerUp ;$00570C06;AC_VERB_SET_EAPD_BTLENABLE;ExternalAmplifierPowerUp+SwapL&R $0063B03F;AC_VERB_SET_AMP_GAIN_MUTE;max_vol;R+L;AD1981HD-headphones End If you like to test swapping Left and Right channels, unlock third verb. Should be working according to Intel's High Definition Audio Specification (Chapter 7.3.3.16), AND if supported by your codec, but not tested in this thread so far. Also I added set max volume to volume widget '06', just in case you want to use 'VolumeWidget=$05' in HDACFG.INI to set speaker volume with WAVEOUT.EXE BTW I never tested doubling this line in HDACFG.INI, like: VolumeWidget=$05 VolumeWidget=$06 In HDALOG.TXT can the result be seen, if any. If it is working both headphones and speaker volumes should response to settings of WAVEOUT.EXE. I found some information about AD1981HD in Linux sources, 3F should be max volume (63 steps) and BF should be the default state indeed. Good! BTW there are two interfaces to sent verbs with INTELHDA.EXE: called 'Immediate Command' and 'CORB/RIRB'. I doubt this is possible, but you can try SPEAKER.DRV - just search for 'KB138857'. A program should be interconnected with HDA2.DLL, that is out of my reach. I am not a programmer, not even an engineer. But you can try to make changes to HDAICOUT.HDA on-the-fly, so WITHOUT rebooting. If I am reading Intel's High Definition Audio Specification right, the so called 'Link protocol' mentions max 256 verbs can be sent from a buffer, and also every digital audio 'frame' can contain ONE verb sent and ONE response to be received back. I have never tested this, so you would be the first HDA2.DLL-user EVER. However, I don't know about the 'handling' of HDAICOUT.HDA by HDA2.DLL: if verbs are sent only during codec-initialization, this is a no-go of course.

I am happy your speaker is working. But before I respond: I'd like to see HDAICIN.TXT/ v12, didn't found the folder. Maybe not set to public?

I can't do anything to help you, OR just ask for help and don't try to understand every 'bit', OR make free time (suggestion: no gaming for next month). You did well, but you forgot to address 'channel 1' with SET-verbs. Also I asked to make comments with the 'right' description after a semicolon after each verb. Also you forget to test the EAPD verbs for widget '05'. Not in your case. There are two classes of verbs. The verbs: A/2, B/3, C/4 and D/5 use only one of the five digits left after addressing 'Codec Index' and 'widget'. So 4 bytes left = 16 bits. The other verbs: Fxx/7xx has only two digits left for payload, so 8 bits. First two digits are used for addressing inside the widget. Meaning of GET verb: B 80 xx addresses 80 = Output Amplifier, Right, channel 0. The other: B A0 xx addresses A0 = Output Amplifier, Left, channel 0. Remember it is stereo! Meaning of SET verb: 3 90 xx addresses 90 = Output Amplifier, Right, channel 0. The other: 3 A0 xx addresses A0 = Output Amplifier, Left, channel 0. Last two digits xx are the volume level. 80 means muted, 00 - 7F is level in 127 steps (some codecs have other specs, so 1F is a good compromise). If GET verbs response is only 80 OR 00 this means there is no volume level available, only mute/ un-mute. No, the final goal is to find the PIN-widget which drives your speaker, and configure this widget to 'activate' your speaker. Because your datasheet does not give full verbs, we have to experiment according to Intel's High Definition Audio Specification. We have to include the GET-verbs because only these verbs gives meaningful responses in HDAICIN.TXT. Just like asking questions in a Forum, only 'reading' the 'answers' is a bit more complicated because the 'language' involved is 'machine language' consisting of bits with value '0' or '1' (the eight hex-decimal digits are only a 'handy' representation of bits). You didn't finished the required tests of this 'Level'. So 'Game over' - it's really like gaming.... To speed up things I added HDAICOUT.SIN to this post to test PIN-widget '05' (Line-out). So just rename, reboot and ONLY upload HDAICIN.TXT Yes, always un-mute your speaker if there are any WORKING physical buttons on your laptop. Headphones are already working, so these are not needed. Just read my post of May, 20 again. We already identified the signal path to your headphones. So Widgets '03' and '06' are DONE, already correctly configured by HDACFG.INI. In case of your speaker the other four PIN-widgets are left as potential candidates (port's B, C, D and mono-out - if this widget really exists in your codec). Not until you have made plenty of spare time (see my suggestion earlier in this post). HDAICOUT.SIN

Thanks for testing 'pcipatchB'. About HDATSR, there is following workaround described earlier in this tread. In case of Windows ME obligatory, because ME can't load TSR's. AUTOEXEC.BAT (.......) REM HDATSR SYSTEM.INI (.......) [386Enh] (.......) MaxPhysPage=40000 (.......) HDACFG.INI (.......) [BUSMASTER] myPCIHI=$4012 myPCILO=$0000 myPCI=$40120000 aPCIHI=$4011 aPCILO=$0000 aPCI=$40110000

Looks good as such, only last line should have been: $00C3B180;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel1 IF you wanted to mute Channel 1 on widget 0C (the payload is 12 16 bits in case of the 'B'-verb). Some laptops seem to have a manual mute-switch, still working if driven by HDA2.DLL. As such we are done. To close this file I would like to know if 'pcipatchB=$7900' is really necessary on your system. So if you would be so kind to test with 'pcipatchB=$0000' I would be very happy.

Good! I think Watler did a good job with the widget settings in HDACFG.INI. Only finding the right widget number is not always easy. But don't forget the brute-force method, just trying all numbers from '$01' up to, say, '$26' (hex!). Only 2x16+6 = 38 reboots needed.... About the sound with the '00000000'-value, it is possible this sound came from other channels. I experienced this on my own codec ALC662. You can try to mute the other mixers by changing some verbs in HDAICOUT.HDA. In my quasi-universal design ALL widgets are set at max volume (but will only 'listen' if they have the capability to change output volume: $00C3B01F;AC_VERB_SET_AMP_GAIN_MUTE;max_vol etcetera (in fact ALC888 supports '7F', but @sweaterfish found out this was not supported on his codec and gave issues). So you can try to mute the other mixers: $00D3B080;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel0 $00E3B080;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel0 $00F3B080;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel0 $0263B080;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel0 Maybe muting the loopback-signal path is needed too, this time mixer 0C included: $00C3B180;AC_VERB_SET_AMP_GAIN_MUTE;mute-channel1 and so on. But I think this is unlikely, Channel 1 will be muted in the default state.

It seems volume setting of WAVEOUT.EXE is written by HDA2.DLL to the [Volume] section in HDACFG.INI. So WAVEOUT.EXE seems to be okay. Manually copying WAVEOUT.EXE makes no difference. How about if listening with headphones, any difference? Please try both 'VolumeWidget=$02' and '$25' and report. Edit: Some Alsa-sources mentions nodes 0C and 26 in relation to output volume. So you should try '$0C' and '$26' too.

@Dave-H Thanks for mentioning WAVEOUT.EXE. @RU-B0 Did you need to select a Device and is the first white screen populated after pushing the button in the upper left? Further in HDACFG.INI the right widget must be set. In the last version of your HDACFG.INI you set 'VolumeWidget=$25' - maybe 'VolumeWidget=$02' will be better. According to the datasheet of ALC888S other possibilities are '$03', '$04' and '$05'. @awkduck Thanks for clarification. Would be a nice project.

@awkduck I agree in case of updating drivers or files like EXPLORER.EXE already installed by Windows' SETUP.EXE. But can you record any successes if INF-files are involved (not installed by SETUP), no need for CUSTOM.INF ?

Nice result, only @Dave-H tested HDARUN.EXE so far in this thread. I studied your files, and I have some bad news and some good news. The bad news is you made a mistake in your earlier tests: you set 'mytimer=0' in HDACFG.INI. So HDA2.DLL will ONLY work with HDARUN.EXE (this setting is actually targeting HDARUN.EXE). Sorry, I overlooked this the first time. The good news is you can try 'mytimer=1' and repeat all tests WITHOUT using HDARUN.EXE. Please report your results, you are the first in this thread using codec ALC888 !

@sifonium thanks for test v10. Now CODEC-info lines are populated normally. Below my comments on responses to the GET-verbs you sent with your HDAICOUT.HDA Legenda: 8-bit order: bits 7654 3210 (bit3=2^3, bit2=2^2, bit1=2^1, bit0=2^0) sent $005B8000; got $000000BF => BF should mean on bit-level: 1011 1111 sent $005B8001; got $000000BF => so bit 7 = 1 => muted sent $005BA000; got $000000BF => (Bh=11=1011, Fh=15=1111, 'together' BFh) sent $005BA001; got $000000BF => same sent $006B8000; got $000000BF => same sent $006B8001; got $000000BF => same sent $006BA000; got $000000BF => same sent $006BA001; got $000000BF => same sent $007B8000; got $000000BF => same sent $007B8001; got $000000BF => same sent $007BA000; got $000000BF => same sent $007BA001; got $000000BF => same sent $009B8000; got $000000BF => same sent $009B8001; got $000000BF => same sent $009BA000; got $000000BF => same sent $009BA001; got $000000BF => same sent $018B8000; got $000000BF => same sent $018B8001; got $000000BF => same sent $018BA000; got $000000BF => same sent $018BA001; got $000000BF => same sent $005F0700; got $00000040 => set to Output sent $006F0700; got $00000040 => set to Output sent $007F0700; got $00000040 => set to Output sent $009F0700; got $00000020 => set to Input sent $018F0700; got $00000020 => set to Input sent $005F0100; got $00000000 => Connection Index = 0, selected is lowest connection '1' sent $006F0100; got $00000000 => same sent $009F0100; got $00000000 => same sent $00BF0100; got $00000000 => same sent $018F0100; got $00000000 => same sent $005F0800; got $00000000 => Bit 7 = 0, so unsollicited response disabled (probably*) sent $006F0800; got $00000000 => same sent $009F0800; got $00000000 => same sent $018F0800; got $00000000 => same sent $005F0C00; got $00000000 => Bit 1 = 0, so EAPD pin state is low (probably*) *taken from a Realtek HDA codec datasheet BTW I removed the tick-responses! To proceed I suggest to use a HDAICOUT.HDA with SET-verbs between two corresponding GET-verbs, so changes made by SET-verbs can be detected. Further try ONE output-widget at a time. Best start with 'NID: 05'. Also it is a good habit to end each line with a semicolon and as comment the (more or less) official name of the verb. Most names you can find in my excel notes, or in a box in INTEL.HDA.EXE: BTW above all payloads are zero's! Most of the payloads you can find in my quasi-universal HDAICOUT.HDA, or you can copy/ paste the needed SET-verbs. For now I would suggest not to play with 'unsollicited response', but always try with and then without 'AC_VERB_SET_EAPD_BTLENABLE (although 'officially' supported on 'NID: 05' only). The SET-verb of AC_VERB_SET_EAPD_BTLENABLE will be 70C02 Upload same files please.

@sifonium your HDAICOUT.HDA looks good, only better no empty lines (or use a semicolon on empty lines). Currently I am deciphering the responses. But I found your codec is no longer identified in HDACFG.INI. So please repeat your experiment. I also will need HDALOG.TXT

Hello @RU-B0 - so trying HDA2.DLL? I hope you are sure about this, because I foresee a number of problems, which can take lots of time. But on my side: I am ready to go! Sorry to say, but at first sight I don't agree. According to your HDACFG.INI your High Definition Audio Controller is 8086:293E which is a known HDA controller. Even a C33-subsytem is mentioned on 'The PCI ID Repository'. Also your HDA codec is found by HDA2.DLL: CODEC_VID=$10EC and CODEC_DID=$0888 is actually ALC888. So far so good. According to your HDACFG.INI you have 'CODEC Index=$0', so I am afraid using HDAICOUT.HDA written for 'CODEC Index=$2' is not a good idea. NO offense of course! I am not sure if I fully have understand your post, but if the slider of a player is not moving: this is bad. Can't be cured with HDAICOUT.HDA however, because the communication with the HDA controller must be (re-)established first. I can suggest following: setting 'pcipatchB=$7900' in HDACFG.INI (be aware: writing to PCI Controller Registers is always at your own risk, if any) set in HDACFG.INI: SleepingWidget=$02 (OR $25) VolumeWidget=$02 (OR $25) OutputWidget=$02 (OR $25) use for now my quasi-universal HDAICOUT.HDA, version 'Codec Index=$0' (last version in my Post of May, 12) always use with headphones if you can hear the slightest sound, or only the 'Sound of Silence' Your codec ALC888 is a so called 'High End Codec'. In the datasheet of your codec (I assume ALC888S is the right version, because I found ALC888-GR, ALC888DD-GR and ALC888H-GR exists too) can be seen there are several playback possibilities (see below my playback-adjusted version): I am afraid the default setting of all PIN I/O-complexes is 'Input'. BTW mixer '0B' is input-related, but output of this mixer can be redirected to the playback path. If you want to continue, please report your results. If you need more help, I will need your new HDACFG.INI and HDALOG.TXT only.

Be aware I am not a programmer, just an 'ordinary Joe'. Watler programmed the driver, targeting Win3.x - I found out possibilities to use this 16-bits driver on Windows 98SE. No offense, this is normal. You are a user with a problem to solve. Yes. You cannot add more nodes to HDACFG.INI (as far as I know). Changes regarding the HDA-controller: you tried already all possibilities, also setting other VerbInterface and Wait-states. Best is to start with a new one, I will give some suggestions in the second part of this post. Files involved are HDA2.DLL, HDACFG.INI, WAVEOUT.EXE and if needed a more 'tailor-made' HDAICOUT.HDA for AD1981HD. First concentrate on my notes in Excel: sheets 'AD1984' and 'pin-complex verbs'. You also can search in this thread on 'AD1981' and 'AD1984'. My experiments with 16-bits drivers and SMARTDRV.EXE are all related to missing Win9.x drivers on newer motherboards. I started with Window 95 OSR1 on a HD Vectra 66 MHz, fully compatible. This system was rock-stable but rather slow with 8 MB memory. A few boards later I decided to upgrade to Windows 98 SE because of FAT32, USB-support and DirectX 8.1 and higher. Although I am not a gamer, I liked MS-DOS Prince of Persia 1 & 2 and I wanted to play 'Sands of Time'. But I never succeeded to climb out of the Cave.... Later boards from the XP-area where already more difficult regarding finding Win9.x compatible drivers for integrated AC'97-soundcards/ Ethernet. I always bought used boards, most of the time with Ali/ VIA and SiS chipsets - which are not always 'easy'. But so called 'modern' motherboards from the Vista-area and later, some integrated devices lacks Win9.x drivers. Like: SATA, AHCI, Ethernet, High Definition Audio and sometimes USB. R. Loew made commercial Win9.x patches for SATA, AHCI and more (his heirs made them 'free'). In case of USB there is NUSB, but also the USB-part inside U98SESP3.EXE. In case of Ethernet most Vendors are offering NDIS2 DOS-drivers (16-bits), which can be used with Win9.x - but in case of High Definition Audio there are no commercial Vendors. So one has to use older compatible PCI cards, USB-audio (both not High Definition Audio) or Watler's 16-bits driver. To answer your question: earlier I tested High Definition Audio on 32-bits Virtual Box (I believe v4.2), which was very 'bad'. Later I could use 64-bits Virtual Box 6, High Definition Audio was better, but 'not good'. Lately I updated to Virtual Box 7, so I thought it's time to do some new tests (at the moment I am listening to a nice playlist with GOM player, using HDA2.DLL). ------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------------ Regarding to your laptop speaker: I want to make some comments about your laptop and your codec AD1981HD and the I will make some suggestions how to proceed with HDAICOUT.HDA. First let's have a look on the Functional Block Diagram of AD1981HD. I made the non-essential parts black and I colored some parts: Your current signal path for headphone playback is colored red, you can see only nodes 'NID: 03' and 'NID: 06' are involved (GAM is the amplifier, where volume can be set). Regarding your speaker: according to your laptop manual you have a mono-speaker. So 'NID: 07' is a possibility. In case of Mono-out with 'NID: 07' there are two other widgets involved: 'NID: 0B', a selector widget and 'NID: 0F', a summing (mixer) widget. But sometimes external amplifiers are used, so PIN-complexes 'NID: 05', 'NID: 09' and 'NID: 18' are possible too. They all have I/O-capabilities. But before we proceed we have to know to which verb these widgets/ nodes are 'listening'. Luckily I found a widget table with verb support in the datasheet: Mono-out and all PIN-complexes supports verbs regarding, Amplifier Gain/ Mute and PIN-widget control. PIN-complexes also have internal Connection Select, Mono-out uses external widget 'NID: 0B'. Summing widget 'NID: 0F' has no verbs, just mixes L/R to mono (I think this is the meaning of the grey arrow!). Further all PIN-complexes support verbs regarding Unsolicited Enable and Port D ('NID: 05') EAPD too. So 'best' is first to sent GET-verbs to these widgets, to get their current state by interpreting the response values in HDAICIN.TXT. Suggested GET-verbs for HDAICOUT.HDA: Amplifier Gain/ Mute: B8000 & B8001 & BA000 & BA001 (always 4 verbs to be sure !) PIN-widget control: F0700 Connection Select: F0100 Unsolicited Enable: F0800 EAPD: F0C00 For now I would suggest NOT using the '7FF' Reset-verbs, maybe your BIOS is giving widgets some presets (I am not sure about this!). Do you think you can manage to finish your own HDAICOUT.HDA to read-out specified widgets/ NID's ?

Your welcome. Unexpected results, a real break-through! Congratulations. In my language we say "De aanhouder wint" (according to Google Translate in English: 'Persevere', which is not a sentence and I doubt it has the same 'full' meaning - never mind. In Croatian 'Ustrajati' - but my knowledge of this language is on the level of 'dobar dan'). The PCI-bus is a quite complex 'thing'. Normally I always advise to disable all power saving measures in the BIOS (laptops need them of course) and now and then 'pcipatchB=$...' has been successful. Suggesting updating the BIOS has been always out of scope for me because of the risks involved. But your case is quite interesting. So other readers of this thread have a potential tool now - if they remember there are risks involved. Side note: lately I have been experimenting with HDA2.DLL on Virtual Box 7. Once my whole Windows 10 x64 system crashed , which is weird! @sifonium you have the real spirit. If you want to continue experimenting with the 'widgetry', you can use my notes made in Excel (see attachment). BTW I don't see the folder with v8 on your Google Drive, maybe you didn't made it public? HDA_Codec-info.xls Post Script: Thanks for the 'v8' files. They solved me a puzzle regarding directing the driver to a certain PCI-Device together with SEARCH=FALSE. In your HDACFG.INI those lines are now: PCI_BUS=$00 PCI_DEVICE=$1B PCI_FUNCTION=$0 SEARCH=FALSE This led me to the conclusion the '27,0' showed in your photo of INTELHDA.EXE is not stated in HEX. Because 10h + Bh = 16 + 11 = 27 !!! But sadly this does not explain the behavior of HDA2.DLL on your system before you updated the BIOS.

Strange, for now it is not working. You added the hack to existing [HDA] section already. I overlooked this possibility. I doubt XP-drivers will give any inspiration. Best start commenting out lines in your HDAICOUT.HDA according to the datasheet of AD1981HD until you have 'full' control. But WAVEOUT.EXE will never become working in this way. At best you can mute your speaker or give it a fixed lower volume setting, somewhere between '01' and max - in your case max is probably '1F' ('80' is muted). Instead you can do experiments on-the-fly using other parts of INTELHDA.EXE for sending predefined verbs. There is also a part to read-out your codec (communication can take sometimes more than 60 seconds!).

My suggestions can be (re)grouped in following way: General stability of Windows 9x: numbers 3, 4b, 5a, 5b and 9 suggested to @daguil : - less hardware (video) acceleration - in Device Manager - if-all-else-fails: installation without plug and play bios, so SETUP /p i (watch the space in between in /p i) Stability with HDA2.DLL: numbers 1, 2, 4a, 4c, 4d (together with use of 'SMARTDRV .EXE /X /L /V /B:57344') suggested to @daguil : - not using EMM386.EXE - enabling virtual memory - change in Device Manager role of this computer to Networkserver - set slider of read-ahead buffer of hard disk to max (64 KB) Targeting the HDA-controller: numbers 6a, 6b and 6c Targeting HD-Audio quality: numbers 7 and 8 suggested to @daguil : - updating DirectX to latest supported version About your questions related to HDA-verbs: most can be answered by reading parts of this whole thread A COUPLE OF TIMES (I am not joking) Yes. Please read again my explanation to @Vigami , you missed some points. My quasi-universal HDAICOUT.HDA is sending a few SET-verbs to ALL specified Widgets. Widgets ignore verbs they are not programmed for. So with help of the datasheet of AD1981HD you can try to find out which verbs are really necessary on your system, making your own version. Sadly this datasheet gives no specification of widget-functions (with the bits involved), so it will be hard to find out the more specific verbs. Example: likely your laptop is using an external amplifier which probably needs access to the EAPD-function inside AD1981HD (EAPD means External Amplifier Power Down). EAPD is once tackled in this thread (with @sweaterfish ). I insist: this is not a good idea. While preparing my answers to you question I found an interesting note about AD1981HD: Source: https://www.thinkwiki.org/wiki/AD1981HD So experimenting with BIOS setting and thee three versions of HDA2.DLL ('J', 'K' and 'L') is still an option However I found another route to force HDA2.DLL to use the right 'Codec Index'. According to Watlers post version 'L' has this function onboard. See: http://www.win3x.org/win3board/viewtopic.php?p=202280&sid=c68fab43b7aea22ff8956de23674c058#p202280 Your current PCI-specs in HDACFG.INI are: [HDA_284B8086,30C8103C] ...................... PCI_BUS=$00 PCI_DEVICE=$1B PCI_FUNCTION=$0 ....................... The new section of version 'L' looks like this (empty values): [HDA] PCI_BUS=$ PCI_DEVICE=$ PCI_FUNCTION=$ SEARCH=FALSE You used already INTELHDA.EXE. The print-screen you uploaded to your Google Drive suggest some values: So FIRST try following: [HDA] PCI_BUS=$0 PCI_DEVICE=$27 PCI_FUNCTION=$0 SEARCH=FALSE I suggest to insert this section just above section [HDA_284B8086,30C8103C] with one empty line between them. I would like to see your HDACFG.INI together with HDALOG.TXT. Addendum: Also possible is to change lines inside in your current HDACFG.INI only. I can't reproduce anything on Virtual Box 7: HDA2.DLL always addresses 'Codex Index' 0 [HDA_284B8086,30C8103C] cardmemregistersLO=$4000 cardmemregistersHI=$E454 Mytimer=1 Verbinterface=$1 wait1=$100 wait2=$100 pcipatchB=$0000 PCI_BUS=$00 or $0 ? PCI_DEVICE=$27 PCI_FUNCTION=$0 or $00 ? SEARCH=FALSE ..........

Very good - big progress. Thanks a lot for uploading HDADRV9K ! You are now in the same situation as @Vigami : your HDA-codec is fully set by the SET verbs in HDAICOUT.HDA. So you will have to do everything with the verbs in this file. However: WAVEOUT.EXE can not work, the driver will not find the VolumeWidget anymore (is sending verbs to the wrong codec, your modem at 'Codec Index=$1' - as you stated already). See https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware-testing-thread/?do=findComment&comment=1243866 About mmsystem.dll: I have no clue, it is strange, but if it's working on your system.... About stabilizing measures: see my suggestions I gave @daguil , your direct predecessor in this thread. Other possibilities (just suggestions, I am tapping in the dark). Warning: experimental approach, so best make changes one-by-one! 1) add MinSPs=32 to SYSTEM.INI [386Enh] 2) add STACKS=9,256 to your CONFIG.SYS 3) reinstall your video driver 4) Open MSCONFIG and try following a. Disable all entries in StartUp(?)/ Run(?) - if possible. DO NOT uncheck SystemTray and LoadPowerProfile b. uncheck (System.ini) ConservativeSwapfileUsage=1 - unless you have a swapfile with fixed size. c. Experiment with various troubleshooting settings (Advanced). d. Experiment with vcache/ MinTimeSlice settings 5) check in Device Manager if: a. DMA checkboxes for all hard drives are checked. b. DMA-buffer is set to 64KB in properties of the Direct Memory controller. 6) in HDACFG.INI you can try: a. pcipatchB=$7900 b. Verbinterface=$0 c. other timings settings than wait1=$100 and wait2=$100 But above all I would suggest 7) disable ALL Sound Events like Windows Startup Sound, etcetera. 8) really important is the setting of mci-wave buffer: 4 seconds (default is 5). mci-wave buffer: 5 seconds (default is 4).Or just add 5 in SYSTEM.INI to the entrance [mci] waveaudio=mciwave.drv 5 9) clean (and if possible defragment/ shrink) your registry with some Win9x compatible tool. BTW earlier I said the change memory address you saw in INTELHDA.EXE will probably mean only there is some free room because you disabled some devices in your BIOS.

If you can't disable your modem in BIOS, then we have to continue with the modem switched on. Physically removing seems much to risky to me. In the past I opened two laptops, but both times I damaged parts. Especially the flat plastic signal cables are easily broken. Also it's likely the modem and audio are on the same chip. Be aware the HDA-controller is identified by HDA2.DLL only, not by Windows. Windows has no inf(ormation) file onboard to identify the controller, so will show an unidentified Device in Device Manager. But the HDA-codec should be visible in 'Sounds and Audio Devices / Multimedia' as part of Control Panel. I studied the files you uploaded and things were as suspected. In the first part of HDALOG.TXT you can see the driver has found the HDA-codec on 'Codec Index 0' , but the second GET-verb retrieved no information and the driver moved on to 'Çodec Index 1'. Here the modem was identified. This time there where any meaningful responses and the driver stayed on 'Codec Index 1', which is the wrong codec. $000F0000=$11D41981 $000F0004=$00000000 $000F0005=$00000000 $100F0000=$00000000 $100F0000=$00000000 $100F0004=$00000000 $100F0005=$00000000 $100F0000=$14F12C06 $100F0002=$00100000 $100F0004=$00020001 $101F0011=$00000000 $101F2000=$00000000 $101F000F=$00000000 $101F000A=$00000000 $101F000B=$00000000 $10324011=$00000000 $10370610=$00000000 $10370500=$00000000 $1063A07F=$00000000 $1063907F=$00000000 Also you can see the SET-verbs sent to widgets '03' and '06' according to your entrances in HDACFG.INI: SleepingWidget=$03 => powered up with '$10370500' VolumeWidget=$06 => volume set to max with '$1063A07F' and '$1063907F' (L/R) OutputWidget=$03 => stream parameters and and channels set with '$10324011' respective '$10370610'. Nothing happens however because of the wrong 'Codec Index'. About your SYSTEM.INI: should work, to be fully sure you can change order in subsection [drivers] to: [drivers] wave=mmsystem.dll midi=mmsystem.dllwavemapper=*.drv MSACM.imaadpcm=*.acm MSACM.msadpcm=*.acm WAVE=HDA2.DLL ;;WAVEHDA=HDA2.DLL But I doubt this will make any difference! You can proceed with following experiments: First: ALWAYS use HDAICOUT.HDA for 'Codec Index=$0' Second: start with HDA2.DLL from version J, then version K and last version L. Always watch in HDACFG.INI if your HDA-codec is identified or there are changes to hear in your headphones. ONLY If this brings nothing, you can try 'pcipathB=$7900' (no quotes of course) and start with HDA2.DLL version J again. Be aware: writing to chipset registers is at your own risk (if any)!" BTW can you do me a favor: please upload the contents of version HDADRV9K to your google drive? I missed this version somehow. I doubt this will make any difference! There will be some memory freed.

Sad, I hoped right version of HDAICOUT.HDA would be of any help. I will have to study some of your files. Can you please upload your CURRENT HDALOG.TXT, HDAICIN.TXT (made with HDAICOUT.HDA for Codec Index=$1). Also I'd like to have your full SYSTEM.INI, because of the erratic behavior with 'wave=mmsystem.dll' you mentioned. This time I checked the codec-entrances in HDACFG.INI, it seems the driver is too quick with skipping Codec Index=$0, so now your modem is identified as HDA-codec. This happens sometimes (see reports earlier in this thread). Now in section [HDA_284B8086,30C8103C] is noted: 'CODEC_VID=$14F1' and 'CODEC_DID=$2C06'. See screenshot below: According to the datasheet of AD1981HD you provided this should have been 11D41981 (VID/PID - see page 11). But I will have to read HDALOG.TXT to be more sure. How about if you switch your modem off in your BIOS, and then try again. First without HDAICOUT.HDA, then with HDAICOUT.HDA: for "CODEC Index=$0". So three sets of HDALOG.TXT and HDAICIN.TXT needed.

Hello @sifonium you studied use of HDA2.DLL already. About your question regarding HDACFG.INI: SleepingWidget=$03 OutputWiget=$03 are according to the datasheet of AD1981HD. In case of using headphones I would suggest: VolumeWidget=$06 The unknown Device in Device Manager will be the HDA-controller (communicates with the Codec). The 'HDA utility' is working in Windows 7, not 'good' for Windows 10 (as far as I know). Luckily not needed: the datasheet of AD1981HD you uploaded gives the functional block diagram already. About SYSTEM.INI and 'wave=mmsystem.dll' I will have to investigate/ reinvestigate your problem. For now move on with HDA2.DLL version J. I took a look in your HDACFG.INI and I have bad (or maybe good) news: you have to use verbs in HDAICOUT.HDA starting with ($)1....... because 'CODEC Index=$1'. Also you seem to have used the version of HDAICOUT.HDA included with the driver. This is more an example-version how HDAICOUT.HDA can be used (made by Watler). A few years ago I uploaded three quasi-universal versions of HDAICOUT.HDA in this thread. Maybe it's good to upload them again, this thread has becoming quite long in the meantime (only one line is changed in the $1 and the $2 versions, further all max volumes lowered from 7F to 1F - thanks to experiment of @Vigami). I would suggest to try again if the version of HDAICOUT.HDA ment for 'CODEC Index=$1' is making any difference. Please report your results. HDAICOUT.HDA.zip

@daguil I was thinking about the Windows Startup Sound. It could be possible playing of this sound during startup with HDA2.DLL disturbs other startup processes. 16-bits drivers use a mechanism that blocks the computer for a while. So did you try without Startup Sound, any difference regarding Runtime error 202?

That's sad. System sounds do not use a player with DirectSound. WAV-files can be associated with another player, Windows Media Player for instance. I do not know if this is possible for System Sounds. I only use them if I want to test if sound is actually working. If Windows 98 SE has the same problems, maybe your computer can become more stable with: C) less hardware (video) acceleration - in Device Manager. If no change: D) installation without plug and play bios, so SETUP /p i (watch the space in between in /p i). Should be supported with Windows 95 too. This is quite easy in following way: 1) make a new folder, say C:\WINDOWS.NEW and copy at least: COMMAND.COM, HIMEM.SYS, IFSHLP.SYS, DBLBUFF.SYS, SETVER.EXE and SMARTDRV.EXE to this folder. Further copy full folder of C:\WINDOWS\COMMAND to C:\WINDOWS.NEW - so to get C:\WINDOWS.NEW\COMMAND (if C:\WINDOWS is your current Windows folder). 2) Go to a Real Mode MS-DOS command prompt (outside Windows!) an rename: REN C:\WINDOWS C:\WINDOWS.ORG then REN C:\WINDOWS.NEW C:\WINDOWS and you are ready for a new installation from Real Mode (so do not start Windows, boot just to Command-prompt). This way returning to the original installation is quite easy. BTW backup of Program Files and My Documents is always a good idea, having the content of the Windows-cd-rom on your harddisk too. For instance in C:\WIN9525C (max 8+3 !). Otherwise you will need a bootdisk or MS-DOS cd-rom drivers.

Hi @daguil , nice you try Watler's win3x HD-audio driver on Windows 95 (OSR1 or OSR2?). Runtime error 202 is not good. On first sight I would have following suggestions. I Windows check's and balances: A) change in Device Manager role of this computer to Networkserver and set slider of read-ahead buffer of hard disk to max (64 KB?). B) check version of Directx, should be 8.0 (8.0a?). Reboot and compare, sound quality too. II HDA2.DLL specific: A) check in CONFIG.SYS if you are using EMM386.EXE (or EMM386). If yes, disable with REM before. If CONFIG.SYS is not onboard, skip this step. B) check in Device Manager if virtual memory is enabled. 1) you can try 'pcipatchB=$7900' in HDACFG.INI (without quotes) 2) you can try lowest vcache settings possible: MaxFileCache=32 and MinFileCache=32 together with the other two measures you tried already. Please report your results.