Audio driver for Realtek HD Audio Hardware? [Testing thread]

[isolar]

YES!! Nosnoop PCIPatchB=$7900 = Sound!!

So force codec to $0 in Watler's then set nosnoop was the fix.. with correct audio routing of course $01 AFG to $02 DAC to $0C Mixer to $14 LineOut.

I will test with your HDAICOUT and post the results. Very happy! Thank you!

[Guest Drew Hoffman]

All right! So it was the No Snoop flag after all. Watler's driver was originally developed in 2009 and doesn't include the device and vendor IDs of most chipsets newer than that so it won't set up the PCI config registers correctly. (search for NOSNOOP in HDA.PAS to see where you would have to add it. ) 

For my driver I think I need to add a longer delay after resetting the codec before I read from it, it seems that it will still return the VID and PID but everything else will read 0 for a while after resetting. 

Edited February 16 by Drew Hoffman

[deomsh]

3 hours ago, Drew Hoffman said:

Watler's driver was originally developed in 2009 and doesn't include the device and vendor IDs of most chipsets newer than that so it won't set up the PCI config registers correctly.

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?

 

Edited February 16 by deomsh
Addition's

[isolar]

Okay 1st test to try and get the minimal amount of verbs in HDAICOUT combined with PCIPatchB=$7900, SleepingWidget=$01, VolumeWidget=$02, OutputWidget=$02, with Codec Index forced to $0.. only 3 verbs required!

Wait time set to $100 - seems okay with minimal settings such as this - however occasionally the welcome to windows sound does not play so maybe just on the threshold.

Full sound produced with just the following 3 verbs in HDAICOUT:

$01470C02 = LINEOUT_EAPD_ENABLE

$0143F000 = LINEOUT_IN&OUT_L&R_INDEX0_UNMUTE_VOL00 (Volume is carried through from DAC $02 which gets set to 7F in VolumeWidget setting) - Proves the theory of using 3F000 verb is working!

$01470740 = LINEOUT_OUTPUT_ENABLE

SleepingWidget=$01 - Powers up AFG $00170500 (Although not required as AFG already powered to D0 at reboot cold and warm)

VolumeWidget=$02 - Sends verbs $0023A07F and $0023907F to DAC $02 - Sets L&R Out on DAC Index0 Unmute Vol7F. Confirmed 7F set by checking the widget parser in QUERYHDA app. It appears 7F CAN be set on this codec, not 57 as the limit.. 57 is just 0dB.

OutputWidget=$02 - Sends verbs $00224011 and $00270610 to DAC $02 - Sets Stream to PCM, 44.1kHz, 16Bit, 2Channels (L&R), and Stream 1/Channel 0 (Note channel 0 on stereo widget also automatically uses channel0+1 to get L&R)

NOTES:

7FF reset twice verbs not required.

705 Power on verbs not required. Widgets in D0 state at reboot (strange for a laptop).

701 Connect Select verbs not required - automatically index 0 is connected at reboot for NID $0C (connect index 0=$02 DAC) and NID $14 (connect index 0=$0C MIXER) which is fine for direct analogue audio out path.

NID MIXER $0C - Input already unmuted at reboot - although not always the case on other codecs and pc's/laptops.

--Next test I will report with Deomsh last HDAICOUT.--

SIDE NOTE: Regarding IDT Audio codec.. I think I recall getting IDT 92HD75B3X5 Codec operational and one of the stream verbs required a 09 set as payload in either 706xx verb or 2xxxx instead of 10 or 11 (sorry I can't recall which one but might be the trick to getting IDT audio unlocked in Hoffman's driver?)

--EDIT: Sorry for IDT - not stream verb, these are set as per usual.. it was GPI/O on this codec set to 09 payload that woke things up but I will need to refresh this one as I spent some time on it.. I will try to locate the HDAICOUT for it to assist you.

Edited February 17 by isolar
Updated/corrected response to Side Note.

[isolar]

6 minutes ago, isolar said:

SleepingWidget=$01 - Powers up AFG $00170500 (Although not required as AFG already powered to D0 at reboot cold and warm)

VolumeWidget=$02 - Sends verbs $0023A07F and $0023907F to DAC $02 - Sets L&R Out on DAC Index0 Unmute Vol7F. Confirmed 7F set by checking the widget parser in QUERYHDA app. It appears 7F CAN be set on this codec, not 57 as the limit.. 57 is just 0dB.

OutputWidget=$02 - Sends verbs $00224011 and $00270610 to DAC $02 - Sets Stream to PCM, 44.1kHz, 16Bit, 2Channels (L&R), and Stream 1/Channel 0 (Note channel 0 on stereo widget also automatically uses channel0+1 to get L&R)

Small final test and observation on this - setting SleepingWidget and VolumeWidget to $00 to disable them proves AFG does not need powering on at boot, and also DAC is set to Volume 57h at boot - volume checked with widget parser again confirming 57 response. Sound is working. The true minimal configuration. Maybe the initialization timing in Watlers HDA.PAS can be adjusted so codec 0 initializes properly, just like Hoffman is trying to achieve.. Add a small delay after setting GCTL.CRST? For now I will keep the modified HDA2.DLL forcing codec $0 until a different codec index comes my way.

[deomsh]

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.

[isolar]

2 hours ago, deomsh said:

About fixing 'Codec index': can you share your lines please? I assume in Watlers HDA.PAS.

About volume) Possibly 57h is still the max when I listen as I can't hear a difference between this and 7Fh. Seems 7F can be set although loudest volume produced is 57h 0dB. The stepsize in ALC231 matches this codec 0.75dB steps. I always thought 7F would always be max set as all bits of volume set to 1 - 1111111=7F then it works down 7E, 7D, 7C etc and ach drop is the step size until 0, so 127 total possibilities.

About HDA.PAS) Correct it is in HDA.PAS. Here is where to hard code the index:

{// hardware init mixer for first detected codec (bits 0, 1, 2, etc)}
     i:=0;
     while i<=HDA_MAX_CODECS do begin
     {for  i := 0 to HDA_MAX_CODECS do begin}
         if (audio_pci.codec_mask and (1 shl i))=(1 shl i) then begin
             audio_pci.codec_index := i;
             if (hda_mixer_init>0)then break;
         end;
     inc(i);
     end;

Simply change highlighted line to:

audio_pci.codec_index := 0;

This locks onto codec $0 and loops through it for initialization until it responds. Then initializes the mixer? HDALOG seems to show 3 to 4 passes until it responds, so to keep this universal maybe changing the timing of initialization will work.

I believe timing should be set in this function, possibly one of the highlighted lines below:

function myHDAreset:byte;
var i:word;
var L:longint;
begin
{    // disable global controller interrupts CIE and GIE if enabled}
    hda_OUTL (HDA_INTCTL,longint( hda_INL (HDA_INTCTL) and  $3FFFFFFF{(not(HDA_INT_CTRL_EN or HDA_INT_GLOBAL_EN))}));

{    // ---------------------
    // reset controller
    // ---------------------
 }
    L := hda_INL (HDA_GCTL); {AZBAR + HDA_GCTL}
    L :=L and (not(CRST));
    hda_OUTL(HDA_GCTL, L); { reset bit0 of GCTL}
     i := 50;
 while (hda_INL (HDA_GCTL)=1)and(I>1) do begin
  i:=i-1;
  delay1(1);                        {1 ms delay?}
  end;
delay1(10);{ // must read 0 to verify the controller is in reset}

{bring controller out of reset}
    L := hda_INL (HDA_GCTL);    { AZBAR + HDA_GCTL}
    L :=L or CRST;
    hda_OUTL (HDA_GCTL, L);   { set bit0 of GCTL}

i := 50;
 while (hda_INL(HDA_GCTL)<1)and(I>1) do begin
  i:=i-1;
  delay1(1);                        {1 ms delay?}
  end;
{counted down to about 18 for me before turning back to 1}

delay1(10);{must read 1 before accessing controller registers}
end;

[isolar]

I figured a mild workaround for the codec index selection. As the codec initializes I have implemented a text box that pops up asking for the codec index, then sets the codec index value 'i' to what is typed.

This allows the correct codec index to be selected at startup rather than it may miss it and initialize the modem of HDMI Audio or other possibility.

Although this is a manual way to do it temporarily it is proof it can work, so i'm hoping can eventually be automated by receiving a callback from STATESTS to see which codecs are available and auto selecting the correct one.

To achieve this:

At the start of function jhda_reset:boolean; in HDA.PAS

add a line at the bottom of the var section just before begin;-

s: string;

Then replace the lines:

 {// hardware init mixer for first detected codec (bits 0, 1, 2, etc)}
     i:=0;
     while i<=HDA_MAX_CODECS do begin
     {for  i := 0 to HDA_MAX_CODECS do begin}
         if (audio_pci.codec_mask and (1 shl i))=(1 shl i) then begin
             audio_pci.codec_index := i;
             if (hda_mixer_init>0)then break;
         end;
     inc(i);
     end;
     result:= TRUE;
     end;
end;

 

With

 

 {// hardware init mixer for first detected codec (bits 0, 1, 2, etc)}

s := InputBox(
       'HDA Codec Selection',
       'Enter codec index (0, 1, or 2):',
       '0');

i := StrToInt(s);

audio_pci.codec_index := i;

if hda_mixer_init > 0 then
  result := TRUE;
     end;
end;

 

At next boot you can type any codec index and it will initialize that codec. I don't think i'm allowed to post the modified HDA2.DLL here.. is that correct?

[deomsh]

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?

[deomsh]

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

 

Edited February 21 by deomsh
Typo

[isolar]

On 2/21/2026 at 1:20 AM, deomsh said:

Interesting workaround, but you must know your 'Codec index' beforehand.

Yes, a good temporary step to trial a hard lock on to the codec index for now.. but to automate it and bypass the timing bug would be much better which I am looking into.

On 2/21/2026 at 1:20 AM, deomsh said:

Did you try with code in your post before to set both 'i := 200' instead of 'i := 50' in the 'while (...) do' loops?

Yes I realised that there are actually 2 codec initialization functions present and the first one (myHDAreset) is never called, so the 2nd one (jhda_reset) is being used.

Changing as far as 'i : =400' (i := 100 is default for this function) has no success.

Next I attempted to loop through the codec index init 4 times and check the mixer init - starting at index 0 and moving up 1 each time, however HDAlog then started failing 4 times on index 0 and then settled on index 2 so no luck there. As overkill I tested loop through the index 10 times (!!) but this produced 10 codec index 0 init fails... so the required timing fix is elsewhere.

I managed to code in a temporary messagebox that pops up and displays HDA_STATESTS result so I can see which codecs are detected prior to initialization and both 0 and 2 are detected.. so possibly CORB/RIRB reset timing may need to be investigated?

On 2/22/2026 at 1:14 AM, deomsh said:

so it seems commented-out lines are counting too.

Ouch, that makes it tough! Multiple reboots required for full readings of a codec. Noted for future!

On 2/22/2026 at 1:14 AM, deomsh said:

Connection Select Verbs is moved to the end, because these are less important (most of the time default setting already?).

I believe that index 0 in the connection list for connection select is default according to HDA spec. In all codecs i've worked with to find the simplest route for audio out the default connections were always okay.

I am trying a few more ideas to fix the timing and will report back with any success or things to note.

[deomsh]

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

Edited February 23 by deomsh
Typo

[isolar]

Thank you! Some of this confirms what little I understand of the structure. Specifically sections 3.8 I have been looking into and 3.11 I have been attacking. I believe the 521ms wait listed in 3.11 problem 2 is a huge clue..

I also notice in HDALOG with the versions I made to force or select codec 0 specifically, it polls verb $000F0004 (with 0 response) straight after the PCI/VEN ID returned from $000F0000 = 10EC0280, but then polls $000F0005 which is pointless as 05 parameter applies only to AFG, not root node? Then it polls $000F0000 again and gets 10EC0280, but next it polls $000F0002 for Revision ID with success and so on, correctly initializing codec 0. The timing here will be most helpful to know using the fixed codec version, then implement those timings maybe..

[deomsh]

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.

Edited February 23 by deomsh
Typo

[isolar]

8 hours ago, deomsh said:

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).

Aha that makes sense! I did notice in the code a lot of widgets being activated and set but could not see the trigger. The $000F0005 sent me on the hunt as it didn't make sense.

I will try without HDAICOUT tonight and check the HDALOG.

8 hours ago, deomsh said:

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.

I will look into these.

Which version of HDADRV are the logs you posted above from? I forgot to mention I am working with version 9L.

8 hours ago, deomsh said:

I have no problems finding the right codec on my (available) systems. I can't remember if this really has been a problem.

Yes same to report here. I had read about it in this thread but never experienced it until this one. It seems to jump away from codec 0 far too quickly on this laptop.

Out of interest - What does mytimer=1 do in hdacfg?