deomsh

Thanks for testing my next quasi universal HDAICOUT.HDA with EAPD enabled (this version is CODEC Index=$0 only). All 200 lines are logged by HDAICIN.TXT. I only had to reduce the number of 'Power up!' lines a bit. I am afraid I cannot do anything to fix your headphone issue, but maybe you can. IF you where using a headset with three bands on the 3.5mm plug, try a real headphone with two bands.

Two sliders are indeed uncommon. I use WAVEOUT.EXE only to set maximum volume if I use DirectSound aware programs. If they output to DirectSound their OWN volume slider will work. I made a version of HDAICOUT.HDA that sent certain verbs to ALL widgets/ nodes 02h-1Fh, but included EAPD_ENABLE. Please check if there is any difference with headphones. I need HDAICIN.TXT only. HDAICOUT_EAPD_ENABLED.ZIP

Thanks for the info. About a stress test: I believe playing autoreplay a short file many times is different from playing one album. My (unproven, probably 'wild') idea is with autoreplay the driver will be reactivated each time. But you are in an excellent position to test if there is any difference.

Strange that headphones doesn't seem to connect. Do you really hear nothing in your headphones, not the slightest crackle during startup? About speaker volume: is now set to max. Watler's HDA2.DLL comes with WAVEOUT.EXE. Not working if copied to your Windows directory and set VolumeWidget=$02 in HDACFG.INI?

Thanks. Headphone (Node=15h) does not respond to EAPD_ENABLE. Seen the datasheet it's possible headphones are connected to Line-out (Node=1Ah). So I added $1A to HDAICOUT.HDA. I did some fine-tuning too regarding max output volume. Datasheet says 63dB in 1dB steps, so 3F. HDAICIN.TXT needed again. HDAICOUT.HDA.ALC269_v2

Great news. So EAPD is an issue. But first I'd like to see HDAICIN.TXT

@mrfusion92 I did a long search first on your HD Audio Controller, will be SIS996(L). I found no datasheet, but also NO pci quirks in Linux ALSA sources. So for now we should assume the controller is 'good' with Watler's HDA2.DLL. So no pcipatchB in HDACFG.INI. Luckily I found the datasheet of your Realtek codec ALC269, following values in HDACFG.INI are already good: SleepingWidget=$02 OutputWidget=$02 But set: VolumeWidget=$02 I found speaker (widget 14) AND headphones (widget 15) both support EAPD with default '0'. So external amplifiers powered down. Because speaker system looks quite complicated, lets try headphones first with following HDAICOUT.HDA (just rename). BTW I only need HDAICIN.TXT Hdaicout.hda.ALC269

Interesting workaround. Just for the record: still MaxPhysPage=20000 ? Almost the same values (20000 hex is in 4KB pages, so 524288 KB total memory). However better do a sort of stress test with an audio file of say 5 minutes with autoreplay for about 30-60 minutes or so.

I am not familiar with the values noted in HDAICIN.TXT. Special version of HDAICOUT.HDA? Try my quasi-universal version, you will have to use the version in folder HDAICOUT.HDA\Use if CODEC Index=$0. Just copy to your Windows directory and reboot. HDAICOUT.HDA.zip

Sorry, says nothing to me. In the Dell post a special other QFE was mentioned, but I can't found it (also no link in the post). If you are reinstalling already: in my experience with Windows 98SE installations first install with USB and Audio DISABLED in BIOS (if an option). So video first. Second install some USB2 driver and afterwards enable USB and see if everything is working. Then install the audio patch and last enable audio and install driver (AC'97 driver will need access to audio). Because of your shared memory with video: if adjustment is possible in BIOS first, say 32 or 64MB. Setting MaxPhysPage=20000 sounds okay. Maybe in: [vcache] MinFileCache=1024 MaxFileCache=8092 But I doubt vcache will make any difference. And did you install the INTEL inf FIRST, mentioned in the Dell post?

Are you sure it' not GX260? Otherwise maybe this link can be helpful: https://www.dell.com/community/Desktops-General-Read-Only/Windows-98SE-on-an-Optiplex-GX260/td-p/3977581

Thanks. So nothing special. Then there will be another reason for the difference in my case (in fact last time I tested Win98SE+HDA2.DLL on Virtual Box 6 was before I migrated my Windows 10 x64 system to SSD).

Thanks for your kind words. Good luck with your machine. I have a question about your retro-machine: which disk are you using, a 'real' hard disk, or a (fast) SSD? I ask this because the performance of Win98SE+HDA2.DLL was much better in Virtual Box 7 than in Vbox 6 after I upgraded. I first thought this was because of the new version of VBox, but when I had to make a clone of my SSD to a hard disk (because of bad sectors on the SSD), I tested by chance my setup from the hard disk. Now HD-audio was not 'good' anymore. After testing from the SSD again, the 'good' sound was there again. My current theory is the read-speed can be important, but I didn't run any serious tests so far.

Thanks for testing. About your question: if you really use R. Loew's PATCHMEM, why not go for the 2GB settings? If you have any problem: there is always the 1GB option (or less if needed: on Windows 3.1 for instance, or on a low-memory system). But the physical memory addressed in HDACFG.INI [BUSMASTER] must exist. I have no personal experience with 2GB memory in Windows 9x. Many of my contributions to this thread are purely theoretical, also because I have only access to a few High Definition Audio codecs/ controllers.

MSCONFIG has it's own 'ideas', I only use this tool in special cases. I normally use SYSEDIT, I believe already there in Windows 3x. That my 1GB settings are not working is strange. Please be so kind to test again, with SYSEDIT to set MaxPhysPage. I made a typo in this case: myPCI=$3F20000 is missing one zero, should be: myPCI=$3F200000 (print-screen was correct)

I understand, you are using R Loew's patch, probably without a MaxPhysPage entry. In my opinion OR HDATSR.EXE should be used (BUSMASTER values auto-written accordingly), OR write your own busmaster values. I can not judge if/ how the memory address of the HD Audio Controller is used by HDA2.DLL and how the buffer set in memory is related (address of the HD Audio Controller can be found with Device Manager - would have another name, or unknown). My examples can be used on Windows 98SE too. I gave some 'room' for MS-DOS drivers, and the buffer will/ should lie below 2GB too (this in case of 2GB physical memory). So feel free to try, or choose your own way and go without. Please report your results.

Oops, If you used empty tabs: I ment tabs with 'heavy' websites (as far Opera will load them). So, you are using Windows ME? I did the calculations, with following results: HDACFG.INI Busmaster values in memory, 'out of reach of Windows' 1) Comment out HDATSR.EXE in AUTOEXEC.BAT (if needed) 2) Add to SYSTEM.INI [386Enh] Case of 1GB: MaxPhysPage=3F000 Case of 2GB: MaxPhysPage=7F000 (if the entrance already exists with another value: change). 3) Add to HDACFG.INI Case of 1GB: [BUSMASTER] myPCIHI=$3F20 myPCILO=$0000 myPCI=$3F200000 aPCIHI=$3F10 aPCILO=$0000 aPCI=$3F100000 Case of 2GB: [BUSMASTER] myPCIHI=$7F20 myPCILO=$0000 myPCI=$7F200000 aPCIHI=$7F10 aPCILO=$0000 aPCI=$7F100000 BTW this will set an 1MB buffer in [BUSMASTER], according to the limitation of Windows' physical memory access in SYSTEM.INI If someone wants to check my calculations, see the print-screen: I hope this will work, total memory seen in Device Manager should be about 2031MB, please check! Thanks. If I have this issue, I increase number of BUFFERS in CONFIG.SYS, but not possible in 'normal' Windows ME of course. Only needed is case of severe crashes, it's all in the tread. Watler's HDAICOUT.HDA is an example, not a part of the default installation. So just using HDA2.DLL 'version L' didn't do the job in your case. Good to know.

Nice This is possible, but be aware Windows can - without warning - overwrite memory used by the buffer, to sent digital audio to the HD-audio link. Watler states in the readme you have to use memory 'outside the reach of Windows', so a TSR, or by setting Busmaster values in HDACFG.INI. But as long it works for you.... If you like you can do a crash-test with a browser like Opera and open 60 tabs or more, in between watching free memory left with System Monitor (if not available System Monitor has to be installed separately with 'Windows Setup' in 'Add/ Remove Programs'. Very good. Setting both to 1024 are 'only' experimental fail-safe values. If I remember well a user had to set maxfilecache=8192 to switch keyboard layouts. Can you tell more how your setting improved stability on your system? Did you experimented with different values of 'MinTimeSlice' in SYSTEM.INI [386Enh] too? Congratulations, you are the first user ever reporting such a result in this thread. Your volume will be set to max already. The right VolumeWidget is only needed if you want to use WAVEOUT.EXE to set volume. Not needed in case of volume sliders of Players (and Games???) who use DirectSound. As far I can judge Watler started with a widget parser in HDA2.DLL 'version L'. With specific GET verbs widgets can be 'asked' which type they are, etc. Codec's return values can be found in HDALOG.TXT. If everything is right, the driver should sent the 'right' SET verbs to respective widgets (if another state than their default state is needed) and also set the 'right' widgets in HDACFG.INI. With HDAICOUT.HDA about max 200 verbs can be sent to the codec. In my quasi-universal design six important 'standard' SET verbs are sent to ALL widgets 02-1F, so to 30 widgets (some High-End codecs have more widgets!). According to Intel's High Definition Audio Specification widgets 'listen' only to verbs they are programmed for, so most verbs in HDAICOUT.HDA are wasted. Otherwise HDAICOUT.HDA must be tailormade, which is not always easy, as can be seen earlier in this thread. BTW always test first without HDAICOUT.HDA, only use if really needed!

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.