deomsh

Sorry to say, but same missing Kernel32.dll export as above with 'XnView_Classic-1.99.6-win-full.exe' on (my installation) of Windows 95 OSR2.

I was just testing because I was curious about your question. I remember using XnView in the past, but later I became a 'hardcore' IrfanView user, although not everthing is 'good'. Do you want me to test "XnView_Classic-1.99.6-win-full.exe"?

I did more tests with HDA2.DLL and INTELHDA.EXE (AHDAO) on N68C-S UCC with VT1705. First with CORB from cold boot. This time more had to be done with Pin Widget 1Ch and DAC 10h. All in all it was as expected, only default timing (25) was a bit to low (first response zero's). Some highlights: OUTPUT WIDGET POWER $010F0500 => 00=$0000000000000033 $01070500 => NO SOUND $010F0500 => 00=$0000000000000000 OUTPUT WIDGET GAIN $010B8000 => 00=$0000000000000000 $010BA000 => 00=$0000000000000000 $0103B02A => NO SOUND OR CRACKLES $010B8000 => 00=$000000000000002A $010BA000 => 00=$000000000000002A Second I changed to Verbinterface=$0 and did a fully cold boot, Because I forgot to set al Widgets in HDACFG.INI to $FF, I made the changes and did a full reboot. Afterwards I started with the Immediate Command interface from INTELHDA.EXE. Most things where fully as expected, but not all. I copied all response messages. I have no idea what to do with the extra information besides the Verb response, but you will (I assume): OUTPUT WIDGET POWER $010F0500 CODEC 0 forgot Order 23 times! Codec 0 Was Busy 851 times! Codec 0 Sent Data ($00000000) Probably the earlier Power state survived the reboot (through the BIOS)? Enabling music while Mplayer2 was playing, was more or less as expected. But I couldn't get the 'good' response to the Stream format Verb after using the appropiate SET Verb: OUTPUT STREAM: $010F0600 CODEC 0 forgot Order 46 times! Codec 0 Was Busy 1674 times! Codec 0 Sent Data ($00000000) $01070610 => REASONABLE SOUND, LEFT ONLY $010F0600 => SOUND STOPPED CODEC 0 forgot Order 96 times! Codec 0 Was Busy 3467 times! Command 0 Valid but CODEC still busy! Codec 0 Sent Data ($00000000) AFTER EXIT MPLAYER2: INTELHDA NOT CLEAR YET AFTER CLEAR IC NEEDED AGAIN TO GET RESPONSE: $01070610 $010F0600 CODEC 0 forgot Order 256 times! Codec 0 Was Busy 9274 times! Codec 0 Sent Data ($00000010) OUTPUT FORMAT: CODEC 0 forgot Order 95 times! Codec 0 Was Busy 3444 times! Codec 0 Sent Data ($00000031) $01024011 CODEC 0 forgot Order 107 times! Codec 0 Was Busy 3903 times! Codec 0 Sent Data ($00000000) $010A0000 CODEC 0 forgot Order 57 times! Codec 0 Was Busy 2065 times! Codec 0 Sent Data ($00000000) RESTARTED MPLAYER2: NORMAL STEREO MUSIC But with CORB I had no problems to read out Stream format just set. After using CORB 'good' response with Immediate Command too. So maybe you can make some version with CORB? I am willing to test. Full description of all tests in the two attached files. VT1705_CORB_VERB.txtVT1705_IC_VERB.txt

Nice, maybe try xdvd2.sys too (newer). 2018-16-12 version: https://web.archive.org/web/20181020053006/http://optimizr.dyndns.org/dos/drivers.html Oeps, link is 2018-10 now, will make no difference in case of xdvd2.sys

I'd run some tests. The good news is with an old headphone with only two isolating bands in the jack, everything was normal with Watler's driver on VT1705. Balance button of Mplayer2 worked as expected. The bad news is: if I only installed your driver (MSFN version 018) indeed only Left Channel produced sound. I tried to send Verbs with INTELHDA.EXE (from Watler's AHDAO) using CORB, but this gave a blue screen and unresponsive computer. Then I tried INTELHDA.EXE together with HDA2.DLL and not much was needed to get good sound. From my notes: ======================================================================================== PLAYBACKPATH: 1C [PW3] - 16 [MW0] - 10 [AW0] ACTIVATED AFTER FULL RESET - MPLAYER2 IS PLAYING FIRST: $01070610 => HEAVY NOISE LIKE SOUND, WITH VOLUME SLIDER LOW SOME MUSIC HEAVILY DISTORTED THEN: $01024011 => NORMAL MUSIC - BOTH CHANNELS OR: $01020011 => NORMAL MUSIC - BOTH CHANNELS (NEEDS RESTARTING MUSIC) WITH CHECK: $010A0000 => 00=$0000000000000011 EAPD NOT NEEDED: $01CF0C00 => 00=$0000000000000000 IF SET NO DIFFERENCE NOTHING MORE NEEDED IN CASE OF HEADPHONE AT REAR GREEN JACK ========================================================================================= You can read the whole story in the attachment if you like. N68CSUCC.INTELHDA.ZIP P.S. I am nut fully sure about the Mixer 16h, I expected somehow the inputs must be opened because after codec reset: GAIN INPUT AMP: $016B0000 => 00=$0000000000000097 $016B2000 => 00=$0000000000000097 But if, it will make probably no difference in case of your driver. And now I am tired of testing with the CORB.

Great progress! Regarding pcipatchB: maybe Linux sources can be used to make additions to your list (search for 'pci quirks'). Why strange? Widgets will sent unsolicited responses (if this is enabled). Same widgets noted in the Datasheet of VT1705: seven Port's and one (unknown) Vendor Widget. I don't see your math: highest node number will be 10h + 18h - 1 = 27h (highest mentioned in the Datasheet is actually 27). I don't know wich mechanism the codec will use to translate and sent the unsolicited response to the RIRB. Only 'Software' (i.e. the driver) can do something with it. I never 'reached' this level, but you will (soon). Better ask Copilot or study Intel's High Definition Audio Specification. P.S. maybe I mis-read your question about why these other Widgets identifies themselves as AFG too. I looked into it for Widget 0x1C (on VT1705) I am currently investigating to find something useful for @Drew Hoffman . So I looked for an explanation in Intel's High Definition Audio Specification: '7.3.4.4 Function Group Type The Function Group Type parameter returns a value describing what the type of node is being addressed. This parameter is primarily useful for identifying the type of Function Group a node represents (such as Audio versus Modem) but can also be used to identify the type of “Other” or vendor specific nodes. Parameter ID: 05h' And so on... Maybe of interest if searching with other Codec ID than already established as AFG? To be honest, I can't remember I ever realy thought about it. In my humble opinion bytes [0:7] give no useful information here, but byte [8] does in case of targeting 'Software' (I suppose). BTW if some MSFN-members - reading this thread - are still not convinced of the usefulness: each print-screen selection made with WinKey+Shift+S and mouse and directly pasted above, without any extra (visible) use of other programs (Windows 10 , Windows 11 is different - maybe possible to change to 'old' style?).

So working on a Widget parser? Just double checked on Windows 3.1 and Windows 98 SE with your latest HDAICOUT.HDA and the change in HDA2.DLL. I added the lines of my quasi-universal HDAICOUT.HDA to check with sound. On Windows 3.1 no difference, in HDAICIN.TXT 254 lines, so same as earlier (no sound of course). On Windows 98 SE first the desktop seems to freeze, but it took simply a long time to start/ write HDAICIN.TXT. After next test with Verbinterface=$1 same behaviour, delay was about 30 seconds on my stopwatch. Sound and music afterwards where good (on a non-XMS Ramdrive!). Total 3189 lines in HDAICIN.TXT, fully up to the end of HDAICOUT.HDA - quite impressive. I will look in my datasheet-collection if ConnectionList 4-7 exists. HDAICOUT.HDA_BIG_TEST_WIN31&WIN982_on_VT1705.ZIP

I have the impression my output is mono too (same with Watler's driver, where sound is 'good' as such), but I thought my 'extra' headphone cable was the culprit. I will try to test.

You provided more information than I can currently process, because I am rather busy with another project (which is going quite bad, so needs much attention). I will response to one at a time. I compiled HDADRV9L with: function HDAloadcommands(url:string):boolean; {...} while(ICommands.count>0)do begin {while(ICommands.count>0)and(x<255)do begin} First I tested on Windows 3.1 on my Asrock board with VT1705 codec after compiling with Delphi 1: sound worked and my latest quasi-universal HDAICOUT.HDA too. But if I added a bunch of GET Verbs I found in another old HDAICOUT-file in the Windows directory, HDAICIN.TXT was maximized to last Verb sent from 'absolute' line 255 (as seen earlier lines with Begin/ End or starting with ;; are counting too. Verbinterface=$1/$0 made no difference in this respect But if same HDA2.DLL was tested on my Windows 98 SE installation on the same board, in HDAICIN.TXT all 357 Verbs in HDAICOUT.HDA (total 383 'absolute' lines) where logged, with their response. Only difference: with Verbinterface=$1 'ticks' at the end, with Verbinterface=$0 the '+ w g' or '+ !g' too. Was my simple-minded change 'enough'?

Hope so, I will keep you posted. Thanks for the code snippets, I will at least try 'For unlimited verbs in HDAICOUT:' as soon i have more time. Difficult to say. On my main testing system (already in use for almost ten years) Verbinterface=$0 never worked, neither with AHDA0 (which gives choice between both interfaces). So i only have experience with Verbinterface=$1. This is my HDALOG.TXT: $000F0000=$10EC0662 $000F0004=$00000000 $000F0005=$00000000 First IRS change $10EC0662 First IRS change $10EC0662 First IRS change $10EC0662 No sound at all, never! Currently I am working on Asrock N68C-S UCC board with NVidia chipset and Via VT1705 codec. Lately I tested Verbinterface=$0 which gave sound on this board! I did run some first tests with HDADRV9J/K/L and HDACFG.INI wait1/2 in range $25-$500: no real difference found/ heard, but it is just a first start. The content of HDALOG.TXT is still unfamiliar to me: $000F0000=$00000000 $000F0000=$00000000 $000F0004=$00000000 $000F0005=$00000000 CODEC busy again after finishing $00000000 Is this the wrong CODEC ID? First IRS change $11064397 CODEC busy again after finishing $000F0000 First IRS change $00100000 First IRS change $00010001 First IRS change $40000001 First IRS change $18490397 First IRS change $0000000F CODEC busy again after finishing $01070610 How is your HDALOG.TXT? About Headphone output: my memory about 0x1E was wrong, the Headphone playback path is my Excel table was already 'in line' with your earlier findings (0x1E will be SPDIF-out). Of course you can use DAC 0x3 too by changing Connection Select: As you can see I am currently reorganizing my table, plan is to add (max) gain en EAPD. I am not sure about this, I did some reading in a Realtek datasheet, also in Chapter 7 about the Link Reset and Power Management. But these subjects are far from clear to me. 'Close reading' will need much time however. I do not have any real need currently, but if you want to use Unsollicited Response in your code (for instance disable Speaker if Headphone jack is inserted) this can be of more interest if Power saving is een issue too (Battery!). But you seem to be much better equiped in this respect. At least: did you tested Verbinterface=$0/1 with SleepingWidget disabled in HDACFG.INI, i.e. set to $00 or $FF? I wrote 'About Volume: why not set to the max gain available (...)' but I am not a native speaker and I have no idea how a native speaker will read this. Ment is not 7F, but your actual max gain, i.e. 0x57. I still think setting THIS value to 80% is not a good idea, sometimes sound is recorded at a low volume level. That's why I suggested using WAVEOUT.EXE or setting a max volume in HDACFG.INI by default. P.S. if using the second DAC for your headphones output, more is needed (unless the headphones have a physical volume slider).

Alpha-018 msfn version just tested on Asrock N68C-S UCC with HDA Controller 10DE:03F0 and codec 1106:4397 (i.e. VT1705) with Windows 98SE. At first I got loud scratchy noise, Master Volume slider is not working. But the Volume Slider in Mplayer2 is working. If the slider is set to absolute minimum (just not muted), I could hear music from my HELLER.MP3 which corresponds to the music actually recorded in this file. Only much lower 'transposed' and very, very slow. I clocked one minute of music with my stopwatch, this took about 3m40s.

Impressive development. Sad the legal status of the source code is not declared by Watler. I mailed him about a week ago, no answer so far (last contact I had was in 2022 anyway). But maybe you can describe and share some code snippets how you dealt with the timing issues? I do not fully understand what you said about using the Immediate Command interface (Verbinterface=$0 in HDACFG.INI). That audio is more responsive without HDAICOUT.HDA is a known fact, also the shorter the better. What I think I understand you only needs setting EAPD (besides what is set by Sleeping Widget, OutputWidget and VolumeWidget in HDACFG.INI). Is this true for Headphones too? Unlike the setting in the codec dump seems to be not active on your Pin Widgets with headphones amplifier (EAPD as seen in HDAICIN.TXT earlier). BTW is Widget 0x1E your headphone output? Your latest HDAICIN.TXT is very good, (almost) a full codec dump. I suppose you cut some lines by hand? If not, Node 002 is missing twice. I do not fully understand the differences in F05 responses. In what cases appears D3 exactly (or really only with Verbinterface=$0 ?), and if, how does it 'goes away' then? Sending Verb 705 still needed? Also: does boot with or without a charger make any difference, (with and without reset Verbs)? Further your earlier setting of SleepingWidget=$1, I remembered this can (sometimes?) activate all widgets. About Volume: why not set to the max gain available and use [Volume] in HDACFG.INI to lower? Also set if WAVEOUT.EXE is used, so last setting is saved.

Great, this driver-version, it is actually working on Asrock 960GM-GS3 (SB710/ ALC662). I tested wav, mp3, mid and rmi: all GOOD. Volume sliders are working and mute in Mplayer2 too (not available currently with Master Volume). I installed from Device Manager, Master Volume only popped up on Taskbar after disabling and enabling again. Dxdiag: all tests succeeded (only software buffering available), including MIDI Mapper. I checked playback speed with my stopwatch, seems to be correct.

I just tested Alpha-017.2 with Asrock 960GM-GS3 on SB710/ ALC662. Same as Alpha-016/017.1: first one or two notes of music seems to be heard, then repeat these endlessly. Different tone for different music. Sound started only after disabling Master Volume and enabling again. No response on this volume slider, nor in volume slider of mplayer2. Mute button in mplayer2 did not work either. BTW no other sound drivers active.

Nice output. I compared with the Codec Dump, only difference is EAPD in PIN 0x17 (in your case) and some different PIN Defaults (can be programmed anyway). No Jack Colors decoded? Strange Node 0x16 was not identified with Verb 'F000C', but from other responses it is clearly a PIN Widget.

I extended my list in Excel: BTW DID of Realtec codecs are most of time the same as their model number, but not always! About my suggested Line/Headphones Playback path: the actual wiring of a codec can be quite different. This is from a Sigmatel datasheet: Sorry about the confusion, ment is two lines needed: $01270610;AC_VERB_SET_CHANNEL_STREAMID;01 $01224011;AC_VERB_SET_STREAM_FORMAT;44.1kHz_16-bits My list is 'used with HDA2.DLL' only. You can expand with ALSA (Linux) or other information. Here is an overview of HDA-controllers, but full list will be about 80-120 Dev's (AI-guess): https://wiki.kolibrios.org/wiki/Intel_High_Definition_Audio?utm_source=copilot.com BTW as you can see YOUR controller is not mentioned. I'd like to get your output from ALC280, so I can compare with the codec dump. Still many question marks in my list. As an example what I expect: this is my list I made yesterday for VIA VT1705, after I managed to install Windows98SE on Asrock N68C-S UCC (earlier I used my eight years old Windows 3.1 installation). VT1705.ZIP P.S. About the 256 verb-limit: I believe this is HDA-Spec, see Chapters 3 & 4 of Intel's High Definition Audio Specification.

About EAPD: Inverted EAPD is luckily rather uncommon. Here are is an example: https://lxr.missinglinkelectronics.com/linux+v6.15/sound/pci/hda/patch_analog.c I extended my investigation up to 70 documented codecs to generalise for 'common' DAC's and PIN-widgets. I also added (most of the time theoretical) VolumeWidget/ OutputWidget and Line/ Headphone Playback path. My conclusion is that DAC Widget $12 must be added twice to my latest version of HDAICOUT.HDA. So 255 lines now, but I still reach the Get Verb at the end according to HDAICIN.TXT (from my notes for personal use): BTW greyed-out Mixer-In means NO loopback functionality found. About Wait 1 & 2 settings: This make sense. 'Modern' computers are incredibly fast. About VOLUME: There is an example in this thread where low volume setting was needed: https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware-testing-thread/page/16/#findComment-1186989 About NOSNOOP: Good! But try to fix documented/ tested cases only About TO FIX: - $001F0005 is still needed to populate some entry in HDACFG.INI. I tried myself to skip if NID <> 1, but I failed. - Using Get Verbs to 'determine max volume and automatically set to 80% or thereabouts' is a good idea. Did you play 'HDA bauble poker' with your HDADRV9L already? - Setting left and right volume separate will give more control, the GET Verb is not combined! So why? You have enough space, unless you ment the hardcoding of HDAICOUT.HDA in HDA.PAS? - I am curious about 'microphone', what do you mean with 'record'? Do you want to play karaoke?

True you can directly paste (see 'afbeelding' below), but filesize with Irfanview is more economical with highest compression (see Clipboard_xxx.png below). About using Windows-Key+Shift+S you are missing the point: pasting a full print-screen is most of the time unreadable if containing chars, with Windows-Key+Shift+S you can select without using some extra tool like Paint (even without Irfanview). In my opinion this is a good and easy Windows 10 tool for daily use. Sadly Windows 11 gives some dialog after the mouse-selection, with long waiting time going away to make next print-screen selection. If not included in the OS used, there will be numerous snipping tools available. About IrfanView: of course this is not an advise to install such a tool, I just described my method to post pictures on MSFN. To be fully clear: for me 'Description' is not the same as 'Prescription'.

My method (using Windows 10): select on screen with your mouse after Windows-key+Shift+S, paste in Irfanview, save as *.png, than drag the file into your post where the cursor is currently.

I used version 9J. I compared 9J/9K/9L in case of HDALOG.TXT (on Asrock 960GM-GS3 with HDA controller 1002:4383 and codec 10EC:0662): 1) With HDAICOUT.HDA all log's are equal on Windows 3.1 without [VOLUME] setting in HDACFG.INI (written if WAVEOUT.EXE was used). The driver always sent '7F' to VolumeWidget set. On Windows 3.1 responses to GET Verbs sent further good, but on Windows 98SE intermittendly the response to Verb 001F2000 was OR the wrong 'Board_Implementation_ID' OR even zero's (on Windows 98SE with version 9K/9L). Seems also different on how 'cold' or 'hot' my system was; 2) Without HDAICOUT.HDA all log's are almost always equal in size, but intermittendly the response to Verb 001F2000 was or the wrong 'Board_Implementation_ID' (on Windows 3.1) or even zero's (on Windows 98SE with version 9K/9L. Version HDADRV9J seems to be a little 'better', not fully sure). So I think I have timing-problems too, especially on Windows 98SE without HDAICOUT.HDA (needed on my system tested anyway). I also found if the 'right' VolumeWiget is set in HDACFG.INI the volume setting in HDAICOUT.HDA is overruled (on HDADRV 9J/9K/9L). But with WAVEOUT.EXE volume setting can be adjusted and is written into HDACFG.INI. Also overuled in case of OutputWidget: always 44.1kHz 16-bits. But I think the codec will switch to the right frequency if needed? Both tested with sending GET Verbs with AHDA17 version O (INTELHDA.EXE). About Mytimer=$0 This setting in HDACFG.INI was added by Watler in case after a DOS-session sound was 'gone', and/ or in case of problems with virtual memory. So especially useful in case of Windows 3x Standard mode (no virtual memory). Although he said the default setting (Mytimer=$1) should work on Windows 3x Standard mode, on my system/ installation I always needed HDARUN.EXE in this case: Verb 707: On my system payload '0C' introduced noise, that's why I always use '40' as default, but this can simply be changed in HDAICOUT.HDA. Using Input's (payload '20' ) only make sense on codecs with a loopback function, most of the time a Mixer Widget and/ or a Selector Widget. I only used the analog CD-in port, no problems with Vref experienced (maybe not supported?). Unless you want to re-write HDA2.DLL to cover the recording part (currently playback only). About hard-coding HDAICOUT.HDA inside HDA.PAS: It should be possible, but you will loose the flexibility of HDAICOUT.HDA. In case of EAPD: there exist codecs with inverted EAPD (I believe some Lenovo laptop's!). From a more 'overall' perspective it would be more useful to concentrate on the 'controller part' and the codec-identification. But of course: it is all up to you!

Good to hear the report can be of use to your investigation. The polling saved in HDALOG.TXT has always been like this. Good catch $000F0005 (from my notes): I just tested my eight years old Windows 3.1 installation on Acer Veriton M2610G (8086:1C20 and 10EC:0662). Only Standard mode worked, but sound is still quite good (HDARUN.EXE is needed on Windows 3 Standard mode). With HDAICOUT.HDA the file HDALOG.TXT started as usual: $000F0000=$10EC0662 $000F0004=$00000000 $000F0005=$00000000 $000F0000=$10EC0662 $000F0002=$00100101 $000F0004=$00010001 $001F0011=$40000002 $001F2000=$1025C000 $001F000F=$0000000F $001F000A=$000E0160 $001F000B=$00000001 $00224011=$00000000 $00270610=$00000000 $00270500=$00000000 $0023A07F=$00000000 $0023907F=$00000000 And without HDAICOUT.HDA (not needed on this system if Widgets in HDACFG.INI are 'good' - further only needed $pcipatchB=$7900): $000F0000=$10EC0662 $000F0004=$00000000 $000F0005=$00000000 $000F0000=$10EC0662 $000F0002=$00100101 $000F0004=$00010001 $001F0011=$40000002 $001F2000=$1025C000 $001F000F=$0000000F $001F000A=$000E0160 $001F000B=$00000001 $00170500=$00000000 $00C707C0=$00000000 $00C3B000=$00000000 $00C3B000=$00000000 $00D707C0=$00000000 $00D3B000=$00000000 $00D3B000=$00000000 $00E707C0=$00000000 $00E3B000=$00000000 $00E3B000=$00000000 $00F707C0=$00000000 $00F3B000=$00000000 $00F3B000=$00000000 $010707C0=$00000000 $0103B000=$00000000 $0103B000=$00000000 $011707C0=$00000000 $0113B000=$00000000 $0113B000=$00000000 $012707C0=$00000000 $0123B000=$00000000 $0123B000=$00000000 $013707C0=$00000000 $0133B000=$00000000 $0133B000=$00000000 $014707C0=$00000000 $0143B000=$00000000 $0143B000=$00000000 $015707C0=$00000000 $0153B000=$00000000 $0153B000=$00000000 $016707C0=$00000000 $0163B000=$00000000 $0163B000=$00000000 $017707C0=$00000000 $0173B000=$00000000 $0173B000=$00000000 $018707C0=$00000000 $0183B000=$00000000 $0183B000=$00000000 $019707C0=$00000000 $0193B000=$00000000 $0193B000=$00000000 $01A707C0=$00000000 $01A3B000=$00000000 $01A3B000=$00000000 $01B707C0=$00000000 $01B3B000=$00000000 $01B3B000=$00000000 $00224011=$00000000 $00270610=$00000000 $00224011=$00000000 $00270610=$00000000 $00270500=$00000000 $0023A032=$00000000 $00239032=$00000000 So the starting GET Verbs are fully equal. Good to note: without HDAICOUT.HDA there seems to be a rather huge selection of Widgets that are unmuted now (twice!) and all set as output with activated headphone amplifier too. Also DAC-related Verbs are sent twice instead of once (with HDAICOUT.HDA). But thanks to the fourty versions of HDA2.DLL Watler made me for testing, I have no problems finding the right codec on my (available) systems. I can't remember if this really has been a problem. At least on version 8G my codec was correctly identified. Main difference with the version just before I had to test (HDADRV8e) where two new functions: 'function HDA_init(busnu,funnu:word;name:longint):boolean;' and 'function Scan_PCI_HDA_cards:boolean;'. Still there in HDADRVJ with some (minor?) changes.

Nice experiments, you seem to be equipped for this task. Last week I did a quick reading of my Turbo Pascal/ Delphi kid's-book to grasp the structure/ syntaxis of pascal, but the HDA-controller parts of HDA.PAS are far out of my reach however (and no Problem-to-Solve). In the past I once did a full reading of Intel's High Definition Audio Specification, but later I limited myself to the Verb-parts. A few months ago I had to learn and compile nasm, with help of mrexodia I got acess to pi (from pi.ai) in Ubuntu on Virtual Box. Although I think it is not a good idea to try to let AI do the job, AI can be quite helpful for teaching and analysis. I asked pi to write a compliance report of HDA.PAS. No problems found on the Verb-level, but lot's controller related. Maybe you can use it, only about ten pages. HDA_Compliance_Report_HDA.PAS_[pi].rtf

Sound is good with Alpha-017.1 on Acer Verotin M2610G with 8086:1C20 and 10EC:0662. All DirectX tests (only sofwarebuffering available) oke, except MidiMapper (HRESULT = 0x80004005). Volume-slider in Windows 98SE default Mediaplayer is working too.

I tested my latest quasi-universal version of HDAICOUT.HDA (Codec index=$0). First I didn't reached the GET-Verb at the end, according to HDAICIN.TXT. But if I deleted all commented-out lines, everything was fine. It seems the total number of lines was to high, so it seems commented-out lines are counting too. Tested on all three latest versions of HDA2.DLL: HDADRVJ, HDADRVK and HDADRVL. All HDALOG.TXT files stayed nice small. Except for two lines I moved all commented-out lines AFTER first few lines of a section, and the section with Connection Select Verbs is moved to the end, because these are less important (most of the time default setting already?). HDAICOUT.HDA.ZIP