deomsh

Just tested Alpha-017.1 with Asrock 960GM-GS3 on SB710/ ALC662. Same as earlier, still looks like only first two 'tones' are played (different 'tone' for other music file).

Interesting workaround, but you must know your 'Codec index' beforehand. Did you try with code in your post before to set both 'i := 200' instead of 'i := 50' in the 'while (...) do' loops? Currently I can not say anything about the legal status of the code of HDA2.DLL, I never asked Watler. BTW better add original version number to your code, in your case probably HDADRVJ?

I tested Alpha-017 with Asrock 960GM-GS3 on SB710/ ALC662. Same as Alpha-016: first one or two notes of music seems to be heard, then repeat these endlessly. But volume is much lower now. I played a bit with the settings from the HDA.INF, no differences (found in HKLM\System\CurrentControlSet\Class\MEDIA\0018\Settings\ on my system, if I remember well). Following settings ment: HKR,Settings,SkipControllerReset,0x00010001,0 HKR,Settings,SkipCodecReset,0x00010001,0 HKR,Settings,UseAltOut,0x00010001,0 HKR,Settings,UseSPDIF,0x00010001,1 HKR,Settings,UseDisabledPins,0x00010001,0 HKR,Settings,UseDmaPos,0x00010001,0 Same results after full reboot (cannot return from exit to MS-DOS, driver gives yellow exclamation mark in Device Manager).

Nice experiments, I am glad pcipatchB=$7900 did the trick. Earlier I hesitated because your chipset is (still) unknown, but your print-screen of 8086:0F04 seemed to justify an experiment without further documentation. About Verbs needed: the three Widget entries in HDACFG.INI will sent Verbs too. I am puzzeld why the response of the SET Verbs '$0023A07F and $0023907F' value is still 7F (if I understood you well!), *somehow* I expected the max value returned. I looked into Intel's 'High Definition Audio Specification', the relevant information seems to be (Section 7.3.3.7): "Gain is a 7-bit “step” value specifying the amplifier gain, the actual dB value of which is determined by the “StepSize,” “Offset,” and “NumSteps” fields of the Output Amplifier Capabilities parameter for a given amplifier. After codec reset, this “Gain” field must default to the “Offset” value, meaning that all amplifiers, by default, are configured to 0 dB gain. If a value outside the amplifier‟s range is set, the results are undetermined." (bold by deomsh) I am not fully-fully sure anymore if the codec dump with max 57h steps is all the info needed to predict the maximum value, but you can try with HDAICOUT.HDA sending $0023B07F and next time $0023B057 and use your ears if there is any volume difference (best with headphones in my opinion). Also you can study the codec dump and/ or the Datasheet of ALC231 again: The bold part of the quotation above suggests there can be *some* problems if Amplifier Gain (= volume) is set out of range, which supports earlier experiences mentioned in this thread. Nice to hear Verb 3Fxxx is working, I used this inside (and mentioned you too) in my latest quasi-universal version of HDAICOUT.HDA. In Intel's 'High Definition Audio Specification' I find a corroboration (Section 7.3.3.7): "If both bits are set, both amplifiers are set; if neither bit is set, the command is effectively a no-op. Any attempt to set a non-existent amplifier is ignored." This only gives no clue about the input amplifiers of IN/ OUT Pin Widgets, if the Pin Widget set to OUT. If still activated there can be noise introduced, but without loopback to the Playback Path set, I expect no real problems. About Power states: no Sleeping Widgets is *good* in case of HDA2.DLL, maybe less in case of your battery... About Selection Nodes: Realtek codecs seems to set them to the default Playback Path. Same for 'open' Mixer inputs (in this respect ALL my earlier versions of quasi universal HDAICOUT.HDA where based on experiences with Realtek codecs). About fixing 'Codec index': can you share your lines please? I assume in Watlers HDA.PAS.

I asked Watler in August 2017 for help, running Windows 3.1. That time the actual version was Hdadrv6. Until December 2017 I had to test numerous versions, up to HDADRVJ. The only update regarding No Snoop was the SB600 HDA controller in my SB710 chipset. But luckily he added 'pcipatchB' to HDACFG.INI... Next a print-screen of my current list (ment for personal use): Watler was willing to develop his HDA-driver further, but he run out of machines to test. Now and then he has been 'seen' on www.win3x.org. Sadly he had to close his win3x forum (conforums stopped). But just before closing I managed to save most of the forum on the Wayback-machine: http://win3x.conforums.com/index.cgi?board=Pascal&action=display&num=1502071336 I had to test Interfaces too, maybe there is something 'into it' you can use with your timing problem?

Thanks for the WPCREdit image. I think it is time to try pcipatchB=$7900 in HDACFG.INI If you look at address 79h, you can see this is the default in (most?) Intel High Definition Audio Controllers: 08h Because pcipatchB can address ONE Byte only (78h-79h is a Word), so we have to use 79h to set the 'No Snoop' Bit11=0 (it is all in this thread). Lately I asked Copilot again about your Intel High Definition Audio Controller 8086:0F04. This time the answer was going into the 'usual' direction. So it is worth a try, but as always: writing to PCI-devices is at our own risk, if any! I would say in your case: if anything does not 'feels' or 'sounds' right, immediately Power down your machine and reset pcipatchB to its original value (I believe pcipatchB=$0000). Best start without HDAICOUT.HDA and set all three Widgets mentioned in HDACFG.INI to $2 and for now Verbinterface=$1 and wait times to $100 for now. Listen with headphones if you can hear anything, even the slightest 'pop' or 'tic'. Do not use Windows Sounds only, but play some CD-quality music file too. I would like to see HDALOG.TXT and HDACFG.INI (to check). About Verbinterface=$0 giving other response values: I thing your problem is with your High Definition Audio Controller! About ALC3220: is commonly seen as equal to ALC280. I have no ideas about Stream 5. About the Source Code of Watler's driver: when I started with Watler's driver I bought a German book 'Turbo Pascal & Delphi fuer Kids' from Hans-Georg Shumann, including a full version of Delphi on CD-ROM. I once managed to compile HDA2.DLL, but I had no real problem to solve... So I never tried to learn more of Delphi. While I was writing these lines, you recompiled HDA2.DLL already for 'Codec index', so it seemes you are much better equiped in this respect. I will look into it soon. ******************************************************* I made new quasi-universal versions of HDAICOUT.HDA, one for each 'Codec index'. I used your idea to set IN/ OUT together, so all highest four bytes at once in case of the Volume Verb. It would nice if you can give it a try. Lately I wrote all the Codec info in my HDAWIN16 folder to my Nodes List. This gives a broad generalisation, from which I selected the DAC's and Pin's to sent Verbs to. See the print-screen, saved in png-format. I raised the number of Nodes/ Widgets to 2Fh, but only Power up and Volume/ Unmute Verbs are sent to all. Connection Select Verbs sent only to common Pin-D/ Mono-out Nodes/ Widgets (Channel0). This time I included EAPD for all selected Pin-widgets, and GPIO is pre-set as Output for max 8 pin's. GPIO needs THREE SET Verbs, look at my comments in the new HDAICOUT.HDA. I added two commented out SET Verbs (xx is the Node number) to their relevant section: ;$0xx707C0;AC_VERB_SET_PIN_WIDGET_CONTROL;hp_amp_out_enable ;$0xx20011;AC_VERB_SET_STREAM_FORMAT;48kHz_16-bits Further at the beginning/ end of each section the relevant GET Verbs for debugging are added (now commented-out). If I counted right, total number of sent Verbs will be 230, so there is not much room to sent more Verbs, for debugging with GET Verbs, or sending other SET Verbs/ Adresses. Best disable some Select Verbs in that case. HDAICOUT.HDA.ZIP: latest version in

Aha, a Puzzler. Earlier I doubted if I would give you my debug-version of HDAICOUT.HDA so early, possibly disturbing you in your own development. I am more of a Problem Solver: if there is some problem I wake up, if it is solved I loose interest. 1) Not neccessarily, I'd like to see a picture of 8086:0F04 from WPCREdit in 8-bits mode. Please remove HDA.SYS fully in Safe mode before, switch off your machine and wait two minutes before next boot. I also like to know your EXACT chipset, or at least your model number. 2) There is no HDAICOUT.HDA in case of ALC231 in my collection, has been never asked for on msfn. I just downloaded the datasheet in the past, don't know why anymore. 'SPK-OUT+ and SPK-OUT -' will be just electrical characteristics, as such say nothing about GPIO. But you can try the two GPIO settings in the debug version of HDAICOUT.HDA which I commented out. First three SET-Verbs are needed to set GPIO [0], second three for GPIO [1] (NOT their combination). Maybe better rearrange, I made a reconstruction with help of Copilot, I only 'did' GPIO once, with awhooley in another thread: In case of GPIO [0]: $001F1700;AC_VERB_GET_GPIO_DIRECTION;0=input;1=output $001F1600;AC_VERB_GET_GPIO_MASK;0=inactive;1=active $001F1500;AC_VERB_GET_GPIO_DATA;0=GRND;1=High $00171701;AC_VERB_SET_GPIO_DIRECTION;0=input;1=output $00171601;AC_VERB_SET_GPIO_MASK;1=active $00171501;AC_VERB_SET_GPIO_DATA;0=GRND;1=High $001F1700;AC_VERB_GET_GPIO_DIRECTION;0=input;1=output $001F1600;AC_VERB_GET_GPIO_MASK;0=inactive;1=active $001F1500;AC_VERB_GET_GPIO_DATA;0=GRND;1=High In case of GPIO [1]: $001F1700;AC_VERB_GET_GPIO_DIRECTION;0=input;2=output $001F1600;AC_VERB_GET_GPIO_MASK;0=inactive;2=active $001F1500;AC_VERB_GET_GPIO_DATA;0=GRND;2=High $00171702;AC_VERB_SET_GPIO_DIRECTION;0=input;2=output $00171602;AC_VERB_SET_GPIO_MASK;2=active $00171502;AC_VERB_SET_GPIO_DATA;0=GRND;2=High $001F1700;AC_VERB_GET_GPIO_DIRECTION;0=input;2=output $001F1600;AC_VERB_GET_GPIO_MASK;0=inactive;2=active $001F1500;AC_VERB_GET_GPIO_DATA;0=GRND;2=High And so on: their are 8 bits available, so in case of your five GPIO's theory - as far I understand this subject currently - predicts payload '1F' will activate all five together (as Output). Response from the tree GET-Verbs in your HDAICOUT.TXT showed no GPIO-pin's where active! 3) I cannot rule this out, the bit's are indeed different in case of the SET-Verb: In case of DAC's and Mixers this will do no harm. Don't know what happens with Pin-Widgets. I assume: if they can be set as IN/ OUT, probably they will only 'listen' according their initialization with Verb 70720 (Input) or Verb 70740 (Output). I will think about it, could be more economical in case of HDAICOUT.HDA. Sleeping Widget) As you can see in HDALOG.TXT the driver *somehow* skips looking into CODEC Index=$0 too soon. This is known behavior, sadly there is no option in HDACFG.INI to force CODEC Index. But you still can try Verbinterface=$0 (Immediate Command interface, Verbinterface=$1 is the default: CORB/ RIRB). Volume) True, but it is all about setting bit's. As long 'Bit 7' is zero, everything is fine. Setting '7F' was one of my Verbs in my quasi-universal HDAICOUT.HDA: set Volume to max in case of a Volume Widget, or opening output's in other cases. Later I learned '7F' was too high on some codecs, so I lowered the payload to '3F', or even ' 1F'. Vendor Defined Widgets) I was maybe to fast. At least in Datasheet of ALC231 there is some setting mentioned in case of Node/ Widget 20h: Vendor Defined Audio Widget. Seems to be related to some Audio Processing (maybe related to noise reduction?). I am not sure, never tried such an approach. About testing) beter use bigger WAV-files in Sound Recorder or Mediaplayer or mp3 (in case of mp3 some (software-) codec is needed, like the one in DirectX 9.0c). Always use normal CD-quality to avoid switching frequencies, that's why I set you back to the default with '$00224011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits' About Output Pin) Use headphones too, try always all your Jack's. About your HDAICIN.TXT's) The following '4011' responses are 'good': sent $002A0000; got $00000000 ticks=0000001E sent $00224011; got $00000000 ticks=00000023 sent $002A0000; got $00004011 ticks=0000001E and sent $003A0000; got $00000031 ticks=00000023 sent $00324011; got $00000000 ticks=0000001E sent $003A0000; got $00004011 ticks=0000001E But in HDAICIN2.TXT: sent $003A0000; got $00000031 ticks=0000001E sent $00324011; got $00000000 ticks=00000023 sent $003A0000; got $00000000 ticks=0000001E sent $003B8000; got $00004011 ticks=0000001E is strange, seems to be a delayed response. So better try more wait times. $400 is much higher than the default of $100. Did you try to go down to $50, $25., $10 or $5? I also found DAC_3 (probably headphone default, or for Surround sound?) was not set to Stream 1: sent $003F0600; got $00000000 ticks=0000001E sent $00370610; got $00000000 ticks=0000001E sent $003F0600; got $00000000 ticks=0000001E In case of ALC231 it looks like DAC_3 is related to Stream 2. So maybe sending '$00370620' instead? In case of the Pin-widgets I saw '1A' seems to be Input only, so can be probably left out: sent $01AF0700; got $00000020 ticks=0000001E sent $01A70740; got $00000000 ticks=0000001E sent $01AF0700; got $00000000 ticks=0000001E In case of EAPD I saw EAPD was already active on Pin Widget 15h, according to your earlier investigation this is your headphone widget: sent $015F0C00; got $00000002 ticks=0000001E sent $01570C02; got $00000000 ticks=00000023 sent $015F0C00; got $00000002 ticks=0000001E Further testing: try without the both Codec Reset lines too. If you want to post HDAICIN.TXT files again, better give them more descriptive names, or write a 'header' inside.

You have the Real Spirit! 1) Comparing 8086:0F04 only with WPCREdit with and without HDA.SYS will do no harm... 2) True according to 'sent $001F0011; got $40000005', but these are number of pin's only. Unknown if they are used in your laptop and how. I searched for ALC280 with GPIO. They are mentioned in https://lxr.missinglinkelectronics.com/linux+v4.9/sound/pci/hda/patch_realtek.c BTW look at ALC269 too. But most of the time mic-LED or mic-headset related? I also found a codec dump of 10EC0280: https://github.com/yehia2amer/Dell-Precision-T7610-Workstation-Hackintosh-Guide/blob/master/Linux ACPI %26 Sound Dump/asound/codec_dump.txt with 5 GPIO's mentioned. To me it seems almost equal to Block Diagram in Datasheet of ALC231 I have in my collection (ALC269 is a bit different). 3) I didn't mention verb '3F', only as payload in: '3B03F' (channel 0 L+R). I am not sure if your idea of '3Fxxx' is a good verb. For inputs I use 37xxx and for outputs 3Bxxx (both L+R together, more economical in HDAICOUT.HDA). About Sleeping Widget: if HDA2.DLL identifies the wrong codec (you mentioned Codec index $2 - probably your HDMI codec), I have seen earlier in this thread the codec is fully set by HDAICOUT.HDA, while the three Widget settings in HDACFG.INI where not working anymore, and WAVEOUT.EXE neither. Volume: no, there is only one Volume setting per DAC, so if there are 0x57 steps (87 decimal), max will be 57 (hex), so even above 3F (hex)! Power: if you used F0500 you are right if reponse was all zero. Still strange in case of a laptop. But: while debugging I would always Power up all nodes/ widgets. Better test without the two Reset Verbs too. Vendor Defined Widgets: always unknown, never see them mentioned in Datasheets. But now and then identified by Linux guy's (ALSA). But in case of ALC280 I found nothing special so far. For now I have two questions: 1) is the slider moving if you play a sound-file? Just to be sure... 2) Why concentrate on Pin-Widget $014? There are many other possibilities! I did a 'quicky' and made you a debug-version of HDAICOUT.HDA ment for ALC280 only. If you want to test, just rename. Further the usual procedure. ;;Debug-version_1_for_ALC280;HDACFG.INI:Codec_index=$0 Begin $0017FF00;AC_VERB_SET_CODEC_RESET; $0017FF00;AC_VERB_SET_CODEC_RESET;Always_twice! End Begin ;;Node 0x1:Audio_Function_Group $001F0500;AC_VERB_GET_POWER_STATE $00170500;AC_VERB_SET_POWER_STATE;Power up! $001F0500;AC_VERB_GET_POWER_STATE ;;GPIO: io=5, o=0, i=0, unsolicited=1, wake=0 ;; IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 ;; IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 $001F0011;AC_PAR_GPIO_CAP;CODEC_AFG_GPIO_CAP=5 $001F1600;AC_VERB_GET_GPIO_MASK;$00000000 $001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000000 $001F1500;AC_VERB_GET_GPIO_DATA;$00000000 ;$00171600;AC_VERB_SET_GPIO_MASK,00 ;$00171700;AC_VERB_SET_GPIO_DIRECTION,00 ;$00171500;AC_VERB_SET_GPIO_DATA,00 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000000 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000000 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000000 ;$00171601;AC_VERB_SET_GPIO_MASK,01 ;$00171701;AC_VERB_SET_GPIO_DIRECTION,01 ;$00171501;AC_VERB_SET_GPIO_DATA,01 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000001 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000001 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000001 ;$00171602;AC_VERB_SET_GPIO_MASK,02 ;$00171702;AC_VERB_SET_GPIO_DIRECTION,02 ;$00171502;AC_VERB_SET_GPIO_DATA,02 ;$001F1600;AC_VERB_GET_GPIO_MASK;$00000002 ;$001F1700;AC_VERB_GET_GPIO_DIRECTION;$00000002 ;$001F1500;AC_VERB_GET_GPIO_DATA;$00000002 End Begin ;;node 0x2:DAC_1 $002F0500;AC_VERB_GET_POWER_STATE $00270500;AC_VERB_SET_POWER_STATE;Power up! $002F0500;AC_VERB_GET_POWER_STATE $002F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $00270610;AC_VERB_SET_CHANNEL_STREAMID,01 $002F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $002A0000;AC_VERB_GET_STREAM_FORMAT $00224011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits $002A0000;AC_VERB_GET_STREAM_FORMAT $002B8000;AC_VERB_GET_AMP_GAIN_MUTE $0023B057;AC_VERB_SET_AMP_GAIN_MUTE;max_vol $002B8000;AC_VERB_GET_AMP_GAIN_MUTE End Begin ;;node 0x3:DAC_2 $003F0500;AC_VERB_GET_POWER_STATE $00370500;AC_VERB_SET_POWER_STATE;Power up! $003F0500;AC_VERB_GET_POWER_STATE $003F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $00370610;AC_VERB_SET_CHANNEL_STREAMID,01 $003F0600;AC_VERB_GET_CONV;GET_CHANNEL_STREAMID $003A0000;AC_VERB_GET_STREAM_FORMAT $00324011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits $003A0000;AC_VERB_GET_STREAM_FORMAT $003B8000;AC_VERB_GET_AMP_GAIN_MUTE $0033B057;AC_VERB_SET_AMP_GAIN_MUTE;max_vol $003B8000;AC_VERB_GET_AMP_GAIN_MUTE End Begin ;;node 0xC:Analog_Mixer $00CF0500;AC_VERB_GET_POWER_STATE $00C70500;AC_VERB_SET_POWER_STATE;Power up! $00CF0500;AC_VERB_GET_POWER_STATE $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00C37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00C37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00C37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00C37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0xC:Analog_Mixer $00DF0500;AC_VERB_GET_POWER_STATE $00D70500;AC_VERB_SET_POWER_STATE;Power up! $00DF0500;AC_VERB_GET_POWER_STATE $00DB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00DB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00D37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00D37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00DB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00DB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00DB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00DB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00D37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00D37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00DB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00DB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0xF:Analog_Mixer $00FF0500;AC_VERB_GET_POWER_STATE $00F70500;AC_VERB_SET_POWER_STATE;Power up! $00FF0500;AC_VERB_GET_POWER_STATE $00FB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00FB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00F37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00F37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00FB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00FB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00FB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00FB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00F37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00F37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00FB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00FB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Begin ;;node 0x14;[Fixed]Speaker_at_Int_N/A? $014F0500;AC_VERB_GET_POWER_STATE $01470500;AC_VERB_SET_POWER_STATE;Power up! $014F0500;AC_VERB_GET_POWER_STATE $014F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $014F0900;AC_VERB_GET_PIN_SENSE $014F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01470740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $014F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $014B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $014BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0143B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $014B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $014BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $014F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01470C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $014F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x15;[Jack]HP_Out_at_Ext_Front? $015F0500;AC_VERB_GET_POWER_STATE $01570500;AC_VERB_SET_POWER_STATE;Power up! $015F0500;AC_VERB_GET_POWER_STATE $015F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $015F0900;AC_VERB_GET_PIN_SENSE $015F0700;AC_VERB_GET_PIN_WIDGET_CONTROL ;$015707C0;AC_VERB_SET_PIN_WIDGET_CONTROL;hp_amp_out_enable $01570740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $015F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $015B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $015BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0153B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $015B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $015BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $015F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01570C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $015F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x16;[N/A]Speaker_at_Ext_Rear? $016F0500;AC_VERB_GET_POWER_STATE $01670500;AC_VERB_SET_POWER_STATE;Power up! $016F0500;AC_VERB_GET_POWER_STATE $016F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $016F0900;AC_VERB_GET_PIN_SENSE $016F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01670740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $016F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $016B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $016BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0163B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $016B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $016BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $016F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down $01670C02;AC_VERB_SET_EAPD_BTLENABLE;External Amplifier Power-Down $016F0C00;AC_VERB_GET_EAPD_BTLENABLE;External Amplifier Power-Down End Begin ;;node 0x17;[N/A]Speaker_at_Ext_Rear? $017F0500;AC_VERB_GET_POWER_STATE $01770500;AC_VERB_SET_POWER_STATE;Power up! $017F0500;AC_VERB_GET_POWER_STATE $017F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $017F0900;AC_VERB_GET_PIN_SENSE $017F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01770740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $017F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $017B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $017BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0173B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $017B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $017BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x18;[Jack]_Mic_at_Ext_Rear? $018F0500;AC_VERB_GET_POWER_STATE $01870500;AC_VERB_SET_POWER_STATE;Power up! $018F0500;AC_VERB_GET_POWER_STATE $018F0800;AC_VERB_GET_UNSOLICITED_RESPONSE $018F0900;AC_VERB_GET_PIN_SENSE $018F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01870740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $018F0700;AC_VERB_GET_PIN_WIDGET_CONTROL $018B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $018BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $0183B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $018B8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $018BA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x1A;[Jack]_Mic_at_Ext_Front? $01AF0500;AC_VERB_GET_POWER_STATE $01A70500;AC_VERB_SET_POWER_STATE;Power up! $01AF0500;AC_VERB_GET_POWER_STATE $01AF0800;AC_VERB_GET_UNSOLICITED_RESPONSE $01AF0900;AC_VERB_GET_PIN_SENSE $01AF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01A70740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $01AF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01AB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01ABA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $01A3B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $01AB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01ABA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End Begin ;;node 0x1B;[Jack]Line_Out_at_Ext_Rear? $01BF0500;AC_VERB_GET_POWER_STATE $01B70500;AC_VERB_SET_POWER_STATE;Power up! $01BF0500;AC_VERB_GET_POWER_STATE $01BF0800;AC_VERB_GET_UNSOLICITED_RESPONSE $01BF0900;AC_VERB_GET_PIN_SENSE $01BF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01B70740;AC_VERB_SET_PIN_WIDGET_CONTROL;out_enable $01BF0700;AC_VERB_GET_PIN_WIDGET_CONTROL $01BB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01BBA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L $01B3B000;AC_VERB_SET_AMP_GAIN_MUTE;Unmute $01BB8000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_R $01BBA000;AC_VERB_GET_AMP_GAIN_MUTE;Channel_0_L End I hope I made no errors, but please check for yourself. The number of Verbs should just fit I suppose, but you can check with HDAICIN.TXT of course. HDAICOUT_DEBUG_1_ALC280.HDA

@isolar I looked into it, up to a certain extent for now. About 1: My initial idea was you can make print-screens to compare register 8086:0F04 without and with HDA.SYS from @Drew Hoffman but today I searched for the appropriate PCI-registers and couldn't find them. It seems your system has a SoC (System on Chip), not a 'classic' design. In some 4274 pages long Intel Datasheet I found things are different, seems have to do with separate PCI Configuration Registers (probably XT_SNP). So I expect no results. I had some conversations with Copilot during traffic, and it seems it is even possible to damage your hardware in this case. 'While less common, repeatedly writing unsupported values to hardware registers could stress the hardware or violate electrical timing constraints, leading to permanent damage in extreme circumstances.' Normally I use a disclaimer like 'writing to PCI registers is at your own risk, if any' but for now I strongly suggest NOT to write to your PCI registers and NOT try to use pcipatchB (unless you are knowing what you are doing). About 2: I Googled ALC280, so far GPIO not found mentioned in Linux sources! About 3: '$00C3B000 - Unmute Audio Mixer': this is a verb ment for OUTPUT's (3B000). For inputs use: Begin ;;node 0xC:Analog_Mixer $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00C37000;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Unmute ;$00C37080;AC_VERB_SET_AMP_GAIN_MUTE;Channel0_R+L;Mute $00CB0000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_R $00CB2000;AC_VERB_GET_AMP_GAIN_MUTE;Channel0_L $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L $00C37100;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Unmute ;$00C37180;AC_VERB_SET_AMP_GAIN_MUTE;Channel1_R+L;Mute $00CB0001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_R $00CB2001;AC_VERB_GET_AMP_GAIN_MUTE;Channel1_L End Mixer: '$00C70100 - Audio Mixer connected to DAC': as such okay, but I don't expect Selector Widgets before a Mixer. If wanted, better test with GET verbs too: $00CF0100;AC_VERB_GET_CONNECT_SEL;Channel0 $00C70100;AC_VERB_SET_CONNECT_SEL;Channel0 $00CF0100;AC_VERB_GET_CONNECT_SEL;Channel0 $00CF0101;AC_VERB_GET_CONNECT_SEL;Channel1 $00C70101;AC_VERB_SET_CONNECT_SEL;Channel1 $00CF0101;AC_VERB_GET_CONNECT_SEL;Channel1 Note for interested readers: a GET-VERB returns a meaningful payload, can be read-out in HDAICIN.TXT. SleepingWidget: I would set 'SleepingWidget=$02' in HDACFG.INI. Volume: If Volume is set to '00' I am afraid it's minimal volume. Please correct me if I am wrong! Better try a moderate value like '3F'. Next example Verbs are without Node/ Widget address: B8000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_R BA000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_L 3B000;AC_VERB_SET_AMP_GAIN_MUTE;unmute_ch0_L+R B8000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_R BA000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_L 3B03F;AC_VERB_SET_AMP_GAIN_MUTE;set_volume_ch0_L+R B8000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_R BA000;AC_VERB_GET_AMP_GAIN_MUTE;status_ch0_L Power Verbs: I do not understand what you said about your Power States, please explain in (much) more detail. Further: Looks all good to me. Do not forget I have at home only about four different (desktop) High Definition Audio Controllers/ Codecs, all working with my quasi-universal HDAICOUT.HDA and only one HDA controller needed pcipatchB (or set already by Watler's HDA2.DLL, like on my SB710 chipset). I have one laptop from work, but I can not even open a command-line. Booting from USB is out of the question. So I can not run any tests on machines like yours....

Just tested Google again with retrozilla v2.2 and k-meleonW9x v1.5.4. Still working on Windows 98SE. Further still same limitations as mentioned in my post above from September 21, 2025.

Hi Isolar, long time no see. About your question: there are two possibilities, or their combination. 1) Your HD Audio controler needs a nosnoop bit set, you can check with WPCREdit. 2) The parser of WDMHDA identified some verbs you didn't use in your HDAICOUT.HDA. Possible candidates: 'opening' inputs (mixer?), EAPD or GPIO. Search in this thread for verbs.

I tested latest version (WDMHDA Alpha-016) on 960GM-GS3 (AMD SB710) with codec ALC662. I got sound if listening to a music WAV-file in Mediaplayer, but first only ONE intermitting 'tone' or 'tic', and sometimes after replay a highly distorted sound, but no music. According to DXDIAG al tests from a software buffer are 'good' (said oke if I heard sound). For High Definition Audio AMD SB710 seems te be same as SB600. First I checked with Watler's tool INTELHDA.EXE (AHDA17O) at pci-level: Except for Pci-Mem same as (working) W20 $0000 $0002: Re: High Definition Audio « Reply #113 on: Dec 2nd, 2017, 4:57pm » QuoteModifyDelete Post Are the chickens happy again? I think I found something interesting with help of AHDA17L. I compared VERB response values and Register values in AHDA17L after starting Windows with and without HDA2.DLL or BUG.BAT (JUDAS21C). On the codec-level I found no real differences when starting Windows with BUG.BAT in comparison with HDA2.DLL only (apart from some minor volume-levels). Also no differences in HD Audio Controller Memory Mapped Registers. In the HD Audio Controller PCI Configuration Space Registers I found one different value in row W20. TEST: AHDA17L NO DRIVER: HDA2.DLL (98E): BUG.BAT (JUDAS21C): PCI W1:$ W2:$ W1:$ W2:$ W1:$ W2:$ W0 1002 4383 1002 4383 1002 4383 W2 0006 0410 0006 0410 0006 0410 W4 0000 0403 0000 0403 0000 0403 W6 2010 0000 2010 0000 2010 0000 W8 4004 F7FF 4004 F7FF 4004 F7FF WA 0000 0000 0000 0000 0000 0000 WC 0000 0000 0000 0000 0000 0000 WE 0000 0000 0000 0000 0000 0000 W10 0000 0000 0000 0000 0000 0000 W12 0000 0000 0000 0000 0000 0000 W14 0000 0000 0000 0000 0000 0000 W16 1849 7662 1849 7662 1849 7662 W18 0000 0000 0000 0000 0000 0000 W1A 0050 0000 0050 0000 0050 0000 W1C 0000 0000 0000 0000 0000 0000 W1E 010B 0000 010B 0000 010B 0000 W20 0000 0000 0000 0000 0000 0002 W22 0001 0000 0001 0000 0001 0000 W24 0000 0000 0000 0000 0000 0000 W26 0001 0000 0001 0000 0001 0000 W28 0001 C842 0001 C842 0001 C842 W2A 0000 0000 0000 0000 0000 0000 W2C 0000 0000 0000 0000 0000 0000 W2E 0000 0000 0000 0000 0000 0000 W30 0005 0080 0005 0080 0005 0080 W32 0000 0000 0000 0000 0000 0000 W34 0000 0000 0000 0000 0000 0000 W36 0000 0000 0000 0000 0000 0000 W38 0000 0000 0000 0000 0000 0000 W3A 0000 0000 0000 0000 0000 0000 W3C 0000 0000 0000 0000 0000 0000 W3E 0000 0000 0000 0000 0000 0000 When starting Windows with HDA2.DLL only and setting W20/W2 to 0002 enables sound immediately when playing a WAV-file in Sound Recorder. Reset to 0000 disables again, etc. When I counted right, this can be Misc Control 2 Register - R/W - 8 bits - [PCI_Reg: 42h] in the AMD SB700/710/750 Register Reference Guide. So I suspected the interface. I believe Watler's driver HDA2.DLL defaults to CORB/RIRB (Verbinterface=$1 in HDACFG.INI), but can be set to Immediate Command (ports). If I try Verbinterface=$0 I get no sound whatever with Watler's driver. So don't know if that will be a solution....

Hi @Drew Hoffman , didn't expect you in this thread.... I am aware of your project (I am reading MSFN daily). So far I had no time to test your driver, but your project looks promising, in case of Windows 98/ME. About your question: difficult to say. If you search in this thread for IDT, it seems there is one report, working with some quasi-universal version of HDAICOUT.HDA. But that's a while ago... I also 'did' one VIA codec (VT1708B) in this thread, additional verbs where needed in that case. But at home I did VT1705 on Asrock N68C-S UCC without. Somehow Realtek codecs have the 'easiest' architecture, I 'did' a few. ALC66x-ALC88x and ALC1220 have roughly the same nodes and same output pin's Apart from extra's in ALC88x. ALC231/ALC260 are already different. This is in my notes (ment for personal use): The lines in my quasi-universal version of HDAICOUT.HDA focus on a few nodes/ widgets for power up, open the playback path and to set the DAC and volume to default values. Because there are about max 200 verbs free for sending at once, and because in my approach HDAICOUT.HDA is used to sent same verb to 'all' nodes/ widgets, so type of verbs is limited. As such this quasi-universal approach is fully 'blind', no intelligence at all (hopefully some in the maker). All based on Intel's High Definition Audio Specification, NOT on specific Realtek codecs. In most of my versions of HDAICOUT.HDA I have concentrated on output's, but I had plans to make a new version to 'open' input-ampifiers too (mixers). But furthermore ignoring Connection Select will be the price to pay. So maybe you can play with '35xxx', '36xxx' or L+R combined: '37xxx', just an idea. From my notes: Set Amplifier Gain 3 Payload(s) Set Amplifier Gain 3 5 0 8 0 Mute Input Channel 0 R Set Amplifier Gain 3 5 0 0 0 UnMute Input Channel 0 R Set Amplifier Gain 3 5 0 7 F Max Input Volume Channel 0 R Set Amplifier Gain 3 6 0 8 0 Mute Input Channel 0 L Set Amplifier Gain 3 6 0 0 0 UnMute Input Channel 0 L Set Amplifier Gain 3 6 0 7 F Max Input Volume Channel 0 L Set Amplifier Gain 3 7 0 8 0 Mute Input Channel 0 R+L Set Amplifier Gain 3 7 0 0 0 UnMute Input Channel 0 R+L Set Amplifier Gain 3 7 0 7 F Max Input Volume Channel 0 R+L Set Amplifier Gain 3 7 1 7 F Max Input Volume Channel 1 R+L But in case of EAPD, Unsollicited Response and GPIO, things are different and often model-specific (laptops). In that case more information is needed. I only did a few codecs/ chipsets, always on a n=1 basis, with help of study of Linux (ALSA)-sources to find appropiate verbs. However you have a parser, should make things more easy (Watler delivers a seperate parser too in version L, but his driver does not use a parser as such). I am willing to help, but I am not a programmer, just an ordinary Joe with more spare time because I am not interested in sports (no offence to readers of this thread ment of course).

Hello @space223 , can't say, there are no records of this codec with HDA2.DLL. Did you try already?

Please give more exact and accurate information! I use Office 2003 with Windows 10 x64, no problems with Compatibility pack. But this Compatibility pack can not open all docx-files (more specs are *somewhere* on the Internet). For now I made you a test file in Word, saved as docx with Compatibility pack. Feel free to try. Test file for Compatibility pack.docx

You are right, I checked again - this time on Windows 98SE. Only http is working with Google on Retrozilla, but Advanced Search and Cookie-dialogs not. Kameleon 9x same results. Both without KernelEx.

Are you sure it is not something else? Retrozilla (default settings) is still working for me with Google on Windows 95 OSR2. BTW tab with Google: only title is showed.

Sounds difficult. But I can take a look if you are doing something 'wrong'. Please upload followowing files (if available): HDALOG.TXT, HDACFG.INI and SYSTEM.INI (from your Windows directory), CONFIG.SYS and AUTOEXEC.BAT (from your C-drive).

@SweetLow I cited Microsoft. Do you think their '2GB' is a mistake?

@jumper You are right, it's even lower than I remembered. On the other hand the article is stating too: 'Although the user interface is limited to 24 MB, the theoretical maximum size of the cache is actually 2GB.' However Q253912 stated: 'Vcache is limited internally to a maximum cache size of 800 MB.'

Now I think I understand you better. About the comment semi-colon: both ways should work. About 512 MB: I never said that for SYSTEM.INI, the MaxPhysPage=20000 was ment for SYSTEM.CB, so for Safe mode (setting MaxPhysPage in SYSTEM.CB is known as Usher's method - please correct me if I am wrong). About MaxFileCache=56320: this is the officially highest value tested by Micosoft and described in Q108079. MDGX mentions this value it too. My entries in MSBATCH.INF were not ment for running Windows 98 SE in general, but for during Setup. Which is the purpose of MSBATCH.INF

I do not understand, can you give an example? BTW there is some information about the ini-directive here: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-updateinifields-directive Otherwise read 'Windows 98 Resource Kit', Appendix C.

I checked differences as far relevant for playback with HDA2.DLL: only differences concerning default mute/ unmute of Nodes. Unmute outputs is currently taken care of by my quasi-universal HDAICOUT.HDA up to node 1F. However: highest node number in AD1984 is 0x26. Unmute inputs is currently NOT taken care of by my quasi-universal HDAICOUT.HDA because of maximum number of verbs.

Nice. Thanks for reuploading the Linux codec info of AD1984. Now only needed for my 'administration': I want to make a quick comparison with the codec dump (found somewere on the internet) I used for the Thinkpad X61 of @sweaterfish . Good luck with your Thinkpad R61.

Help, your so fast So is everything good now?