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

[deomsh]

These are two unrelated problems in my humble opinion.

If you agree, let's first try to address the chipset with the NoSnoop bit set: if I am right this is the one with HDA-Controller 8086:0F04.

Are you sure about the datasheet, or am I wrong?

I have no opinions about NoSnoop as such: this is far above my level, members like @Drew Hoffman and especially @SweetLow should be able to comment on this. Through the years I did some preliminary investigations in PCI-mechanisms, if I remember well NoSnoop has something to do with use of the processor cache (?).

First I looked in this thread for the phrase 'cold', indeed there are a few posts regarding differences of boot-behavior.

In my (fully empirical) taxonomy I have:

1) Fully cold boot, after shutdown unplugged the power cable, then the power button pressed to unload capacitors/ emptying buffers and waiting at least two minutes before plugging the power cable back and booting;

2) Normal cold boot;

3) Hard reset, only possible if a reset-switch is available. Better not used from inside Windows, but safe if rebooted to MS-DOS command-line first;

4) Warm reboot with Ctrl+Alt+Delete from MS-DOS command-line;

5) Same from inside Windows, should be considered as safe.

I your case I'd like to add:

6) Restart Windows after Exit to MS-DOS and restart Windows with 'WIN' (only ONE time loaded again - so two WIN's visible with 'MEM /a/c/p' afterwards in a MS-DOS Windows inside Windows);

7) Restart Windows after Exit to MS-DOS and restart Windows with 'Exit'.

In my imagination you can try these Options 1-7, but in reverse order. Checking with headphones the Microsoft Starting sound, a small sound file with MPlayer2 of CD-equality, then a big one and in the end your last file (you didn't mention if this one was 'CD-quality = 44.1 kHz or 48 kHz?). Better write down everything. You also can try playing a fully empty WAV-file before, length ONE minute. They should be here or there on the web. In the past I did some experiments in this direction if Watler's driver crashed during playing a soundfile or if restarted not played as it was supposed to be.

As a second pass I would suggest a PRECISE searching inside the HDA-Controller Registers with WPCREDIT (in 8-bits view) for differences. If you find nothing, then other registers mentioned in your chipset's datasheet which are 'looking' DMA-related. I am afraid there are too many... 

Maybe you can use Craig Hart's PCI32 tool to dump registers: https://www.majorgeeks.com/files/details/pci32.html . Then comparing the text-files with some tool.

BTW better use a more recent pcidevs.txt, like this one: http://rh-software.com/index_pci.html 

I 'did' PCI-dump almost nine years ago for the last time, maybe you will have to try a bit to get it working...  In my idea you are supposed to be able to be handle this sort of things. But if not, or you run into some problem, I will of course search and experiment on my system to provide as much assistance as possible.

; ------------------------------------------

P.S. hopefully you will get some idea's after the 'first pass', avoiding the 'second pass' - which will probably bring 'nothing'. I would bet the problem has something to do with not fully emptying the DMA buffer (1 MB?), so maybe the problem is withing *some* HDA2-mechanism. But this is just a non-educated guess. 

 

Edited March 28 by deomsh
Corrections, added P.S. + added print-screen of VID:DID

[SweetLow]

1 hour ago, deomsh said:

These are two unrelated problems in my humble opinion.

JFYI. IDK about any other system but now I can say that definitely on my Intel Core gen 10 system I have some other problem than cache coherence and so No-snoop bits in chipset or PCI-E device or  elsewhere (or I completely misunderstand all things).

To verify this I remembered one test that I used to try to insulate VCACHE problem on newer systems and I just run my system without caching on the processor side at all 

And lo and behold - nothing changes, the same short loops in the end.

[deomsh]

36 minutes ago, SweetLow said:

To verify this I remembered one test that I used to try to insulate VCACHE problem on newer systems and I just run my system without caching on the processor side at al

Can you describe the test you run in more detail, if on the 'user side' something is possible?

Edited March 28 by deomsh
Addition

[SweetLow]

14 minutes ago, deomsh said:

Can you describe the test you run in more detail?

I booted to DOS prompt and disable cache (two methods used - through MTRRs or through cache control bit in CR0) and then run Windows - for clean result.

Booting is painfully slow but possible nonetheless.

P.S. AFAIK this does not disable caching of SM area but I can't imaging scenario that can influences HDA controller using.

Edited March 28 by SweetLow

[deomsh]

I will look into it (and on your site, if I remember well you have some tools or more info there).

But: is what you just described possible too with WPCREDIT and then saving these settings to some reg-file?

[SweetLow]

14 minutes ago, deomsh said:

But: is what you just described possible too with WPCREDIT and then saving these settings to some reg-file?

No, processor caching control is not PCI entity. You can use my package for MSR & MTRR processing (and just use MTRR_RST.EXE from it now) or use "CPUSPD cd" for example for disabling caching in CR0 control register.

Edited March 28 by SweetLow

[deomsh]

I tried with CPUSPD v2.0a, but first I got, while Desktop was still empty a blue screen with 'Fatal error OE at 0177:BFF8976B'. After pressing a button Windows loaded normally and seemed to work. Indeed everything quite slow, only copying files seemed to be normal speed. But MPlayer2 gave 'Error=80040256' - no working audio hardware. If I was going back to the command-line, everything was fine after enabling cache again with 'CPUSPD ce' and starting Windows.

If I remember well I got these type of blue screens in the past (also with some SB-Live PCI drivers) - no chance to get sound afterwards.

If I run the DOS_RM version of MTRR_RST.EXE from the command-line I couldn't start Windows with WIN, sent back on the command-line immediately.

As a last test I thought it would be nice to enable the NoSnoop bit inside Windows with WPCREDIT and then try to run the Win9x version of MTRR_RST.EXE. So I first set value of SB600's HDA-Controller Register at 42h from 0x2 to 0x4: very loud hum from my headphones (if set back to 0x2 everything is fine). But running MTRR_RST.EXE with 42h at 0x4 gave HDA2's famous Runtime error 202, which is quite a heavy crash.

[isolar]

On 3/28/2026 at 9:09 PM, deomsh said:

Are you sure about the datasheet, or am I wrong?

Apologies, I was initially comparing the C220 datasheet and got mixed up. This one is correct for Baytrail 8086_0F04 - Intel Atom E3800 - https://www.mouser.com/datasheet/2/612/atom-e3800-family-datasheet-1522396.pdf - I checked and the registers compared to WPCREDIT seem good. However there are more registers listed here than in WPCREDIT? I believe this is where you mention to use Craig Hart's PCI32 Tool?

0F04 also appears in the Intel Atom Z3600/Z3700 datasheet however I was unable to locate the PCI registers in those datasheets:

https://www.intel.co.jp/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-vol-1.pdf

https://www.intel.com.tw/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-vol-2-329518.pdf

On 3/28/2026 at 9:09 PM, deomsh said:

you didn't mention if this one was 'CD-quality = 44.1 kHz or 48 kHz?

I did some more investigation today and found I was wrongly trying to play a 32bit 48khz wav file (!!) The file is 31 minutes long. This clearly explains why the audio was not playing nice.

So I converted the file to 16bit 48khz and attempted on the IDT laptop. Configured the codec to 48khz and was able to play the file in mplayer2 straight away and it sounded good! However over time playing it was slowing down gradually. I compared it by playing the same file on my PC and played them at the same time and gradually they go out of sync. Any ideas here?

To note: The driver currently auto sets 44.1khz so I had to manually change to 48khz. However, the audio stream did not produce sound simply by changing verb 2h to playload 0011. I had to reset the codec with 7FF using queryhda and then manually send all configuration verbs required to get it to produce sound. I always thought we can change between 44.1khz and 48khz just by re-programming verb 2h on the DAC but seems not. May be something to do with the order of initialization? I believe this is correct:

1. Reset controller
2. Detect codec
3. Get node list
4. Find:
   - DAC
   - Pin
5. Power both to D0
6. Enable pin (OUT)
7. Enable EAPD
8. Route DAC → Pin
9. SET_STREAM_FORMAT (DAC)
10. SET_CHANNEL_STREAMID
11. Unmute everything
12. Start stream

On 3/28/2026 at 9:09 PM, deomsh said:

I would bet the problem has something to do with not fully emptying the DMA buffer (1 MB?), so maybe the problem is withing *some* HDA2-mechanism.

I am of the same opinion here. I will look into how the DMA functions throughout the source code and see if anything jumps out.

Side note: After looking at the mytimer code in DRVPRC.PAS - I did experiment with the mytimer=2 in hdacfg. This made the audio extreeeemely slooow. mytimer=3 broke things and I was unable to boot. The fact that audio speed changed when mytimer=2 was set made me look at the lines where it is set:

Line 430:   if(mytimer=3)then starttime(nil);
    Line 432:   if(mytimer=2)then htime:=SetTimer(0,0,0,@timercallback);
    Line 437:   if(mytimer=1)then htime:=timesetevent(1,1000,  TTimeCallBack(ptr),0,TIME_PERIODIC);
    Line 439:   {if mytimer=0 then use activate}

I will look into these relevant functions and see if anything jumps out.

[SweetLow]

14 hours ago, deomsh said:

then try to run the Win9x version of MTRR_RST.EXE

Yes, it's possible to do this. But

1. it is not clear result as you do calibration of CPU wait loops in one mode (fast with caching) and then use this waits in other mode (very slow without caching). That's why I slow down system before starting Windows, not in running Windows.

2. It is not works always. For example trying to disable WC for non-local buffer in system memory on Radeon PCI-E cards (direct emulation of AGP behaviour) leads to immediate freeze.

14 hours ago, deomsh said:

only copying files seemed to be normal speed

Because it is DMA working, CPU less involved.

[deomsh]

Thanks for clarification @SweetLow 

I tried one last time running MTRR_RST.EXE inside Windows on this board, but this time without HDA2.DLL loaded. My idea was if this was possible, I maybe could activate HDA2.DLL during restart from command-line.

I got a nice MS-Error Dialog while running MTRR_RST.EXE inside Windows, I believe Runtime Error 103, but saving print-screen failed because of crash.

I will look if I can prepare one of my C200-boards. The only I posses that needs pcipatchB=$7900, so maybe a candidate for further testing.

On 3/29/2026 at 1:11 PM, isolar said:

Apologies, I was initially comparing the C220 datasheet and got mixed up. This one is correct for Baytrail 8086_0F04 - Intel Atom E3800 - https://www.mouser.com/datasheet/2/612/atom-e3800-family-datasheet-1522396.pdf

No problem, thanks a lot. Earlier I couldn't find this Datasheet. The NoSnoop bit is indeed present, at the usual offset on Intel-chipset's.

On 3/29/2026 at 1:11 PM, isolar said:

However there are more registers listed here than in WPCREDIT? I believe this is where you mention to use Craig Hart's PCI32 Tool?

WPCREDIT is quite old. But I mentioned Craig Hart's PCI32 Tool because textual dump's should be easier to compare. But it does not seem of use for now, at least if your reboot-problem has been solved?

On 3/29/2026 at 1:11 PM, isolar said:

I did some more investigation today and found I was wrongly trying to play a 32bit 48khz wav file (!!) The file is 31 minutes long. This clearly explains why the audio was not playing nice.

Funny move   But seriously: errors can be quite productive. Maybe try Foobar in case of Audio files, some versions can play 32-bits audio files with 16-bits output.

On 3/29/2026 at 1:11 PM, isolar said:

However over time playing it was slowing down gradually. I compared it by playing the same file on my PC and played them at the same time and gradually they go out of sync. Any ideas here?

I did some tests on my system with the stopwatch my youngest son lent me almost 9 years ago, but no measurable lagging in this case (as far I can see):

Did you try stabilizing measures mentioned in this thread?

On 3/29/2026 at 1:11 PM, isolar said:

I always thought we can change between 44.1khz and 48khz just by re-programming verb 2h on the DAC but seems not.

I am unsure about this, did you compare with the Controller Chapters' in Intel's High Definition Audio Specification? I have no detailed knowledge of these things, if you want me study it, I will try. But will take a few weeks...

On 3/29/2026 at 1:11 PM, isolar said:

I am of the same opinion here. I will look into how the DMA functions throughout the source code and see if anything jumps out.

Good, also the 'somehow nice HDA2-intro' while playing music should have something to do with this. Although I was told 'normal' drivers simply muted the analog audio-stream until the buffer(s) are filled up.

On 3/29/2026 at 1:11 PM, isolar said:

I did experiment with the mytimer=2

I wasn't aware of other values than $0 or $1. Can you please tell a bit more about this subject? 

Edited March 31 by deomsh
Typo's, correction

[isolar]

Hello just touching base to let you know I am still working on everything

Some progress, I have managed to acquire a couple of other laptops to test on and added Conexant 20672 codec into the fray. The other laptop was a Soundmax AD1981HD codec which I already had in a different laptop, but still good to test across different chipsets ICH7 and ICH8. Of interest the ICH7 and ICH8 chipsets have the nosnoop bit set by default but audio still plays without running pcipatch to zero the nosnoop bit. I don't understand why this works without patching, any ideas?

The Conexant codec was on a chipset with nosnoop removal already embedded in Watler's original code and does require the bit to be set to 0, so I have left it in the code along with the other ones from your list @deomsh.

So now HDA2.DLL is loading successfully on 6 different laptops and auto-configuring the codecs to put sound out from DAC to speaker out pin. Setting NoSnoop patch automatically on the ones that require it.

Codecs tested as working are Realtek ALC 272, Realtek HD Audio 280, Conexant 20672, Soundmax AD1981HD, and IDT92HD75B3X5.

Headphone pins are now identified in the widget scan for next update which will be jack detect and auto changing between speaker and headphones.

Digital and mono pins are currently skipped, however I have a feeling there may be some codecs out there that have mono output only? Let me know if you know of any so I can consider.

On 3/31/2026 at 8:08 AM, deomsh said:

Did you try stabilizing measures mentioned in this thread?

I implemented some of the stabilizing methods such as MaxFileCache/MinFileCache = 1024, MinTimeSlice=100, SMARTDRV.EXE /X /L /V /B:57344, PagingFile settings in system.ini and timing for audio is stable now. I duplicated your method with a stopwatch (although my stopwatch not as official as yours!) next to Foobar playing the 31+ minute wav file and it all matches up now wooh! Foobar also has an audio buffer that can be increased for smoother playback which is great.

Next I am going to move onto updating HDA.PAS to be as compliant to HD Audio spec as possible. I am moving into territory that I am unfamiliar with so will take time to wrap my head around memory addressing, DMA, buffers, and all of the HDA controller functions, but think I will be able to make some headway. I still get audio that has a high pitch frequency over the top on a couple of the laptops so think DMA and buffers is the best place to start. Any pointers for this quest very much appreciated!

[deomsh]

Removed doubled post

Edited April 13 by deomsh
Removed doubled post

[deomsh]

Nice, thans for the update.

9 hours ago, isolar said:

I have managed to acquire a couple of other laptops to test on and added Conexant 20672 codec into the fray

I 'did' Conexant 20672 once in this thread, was setting GPIO needed in your case?

9 hours ago, isolar said:

Of interest the ICH7 and ICH8 chipsets have the nosnoop bit set by default but audio still plays without running pcipatch to zero the nosnoop bit. I don't understand why this works without patching, any ideas?

Not sure if I understand. In HDA.PAS I see only NOSNOOP set on Intel 'di=$1E20', is this one of your's? About pcipatchB: I am not sure of setting this will overrule other settings in HDA.PAS. For example (as such unrelated): in case of HDAICOUT.HDA I don't like setting VolumeWidget/ OutputWidget 'overrules' any SET Verb in HDAICOUT.HDA regarding to these.

9 hours ago, isolar said:

The Conexant codec was on a chipset with nosnoop removal already embedded in Watler's original code and does require the bit to be set to 0, so I have left it in the code along with the other ones from your list

I believe pcipatchB=$0000 will do nothing, seems just an 'empty' setting in HDACFG.INI, is written in this way if not set? So is my list ment anyway: Zero's = No patch needed.

9 hours ago, isolar said:

Digital and mono pins are currently skipped, however I have a feeling there may be some codecs out there that have mono output only? Let me know if you know of any so I can consider.

As far I have gone into this subject, I found Mono-output on some Codecs. I believe this is in case of an integrated Amplifier to drive a speaker (laptop's). In the print-screen of my earlier codec-list you can see a lot of codecs with Orange colored PIN widgets. But I assume the 'real' implementation will be model-specific. In that case probably GET Verb F1C00 (Pin_Configuration, from my notes) will find what is 'filled up' by the Vendor. I believe this is one of the codec Pin-Widget settings written by the BIOS. So maybe if you found 'Speaker' with 'No physical port' you can try?

9 hours ago, isolar said:

I implemented some of the stabilizing methods such as MaxFileCache/MinFileCache = 1024, MinTimeSlice=100, SMARTDRV.EXE /X /L /V /B:57344, PagingFile settings in system.ini and timing for audio is stable now.

Good to hear these measures are working for you! Better try a more conservative setting: 'MinTimeSlice=40' because of better multitasking. The highest setting I ever needed was 'MinTimeSlice=120', but that was on a non-XMS Ramdrive with my not-so-stable-AMD710 chipset. Lately I found out disabling Hard Disk and CD-ROM Read-Ahead in Performance Tab of Device Manager CAN be stabilizing too. It cured my problem of fully freezing my system if I only moved my mouse pointer over the CD-ROM drive button in Explorer or Total Commander. Now I can burn a CD-RW (but source files/ image on Ramdrive) while listening to music with HDA2.DLL. Only opening the CD-tray is still too much.

BTW SMARTDRV with /L and the highest Read-Ahead buffer of /B:57344 is a memory hog in Low (DOS) Memory, but in my experience better than loading High. With help of UMBPCI.SYS for instance (Watler warns for EMM386.EXE in the Readme of HDADRV9J/9L). But all these 'things' can be chipset-specific...

9 hours ago, isolar said:

Foobar also has an audio buffer that can be increased for smoother playback which is great.

Sure, I forgot this to mention. I haven't used Foobar for years. So the 32-bits (or 24-bits?) => 16-bits is working with your version?

9 hours ago, isolar said:

I still get audio that has a high pitch frequency over the top on a couple of the laptops so think DMA and buffers is the best place to start. Any pointers for this quest very much appreciated!

Are you fully sure this is not some form of Harmonic Distortion, for instance introduced by high output volumes and fully open inputs (DAC => Mixer), or Headphone Amplifiers? You can try first with more conservative settings: lower Amplifier Input/ Output Gain's and/ or no Headphone Amplifier (Set Verb 70740 instead of 707C0).

About the DMA/ Buffer 'thing', sounds as a 'good' start, but I have no knowledge or experience with this subject.

I tested in the past if NOT using the buffer of HDATSR.EXE and instead placing 'outside the reach of Windows' as Watler called this. But I never found any difference regarding sound quality or otherwise (except about 8KB Low (DOS) Memory less used of course).

It's all in the tread, latest here I believe (watch typo's): 

P.S. your 'hack' for HDAICOUT.HDA above 256 lines is working in Windows 3.1 too. The culprit was een old version of HDA2.DLL in the root of my C-drive, loading first. 

Edited April 13 by deomsh
Typo's, added P.S.

[isolar]

Okay some success clearing the high pitched frequency! I managed to find in HDA.PAS and WOPEN.PAS that the stream format settings in those were conflicting with my widget parser/enabler so disabled any send verbs that Watler's initial parser sent. Nice clean audio at last!

Interestingly now when I set my widget parser to set stream format to 48Khz all of the windows sounds play too fast (quite amusing ) so I set it back to 44.1Khz and all sounds great. I assume the windows startup wav file and windows sounds are all 44.1Khz?

On 4/14/2026 at 4:17 AM, deomsh said:

I 'did' Conexant 20672 once in this thread, was setting GPIO needed in your case?

No, GPIO are not set on any of my test machines - although I have not checked the settings at reboot as to whether they are auto configured after codec reset by the codecs themselves.. Simple path from DAC $10 to Speaker out $1F is found and configured for the Conexant. Headphones at $19, and no mono out present from what I can find.

On 4/14/2026 at 4:17 AM, deomsh said:

In HDA.PAS I see only NOSNOOP set on Intel 'di=$1E20', is this one of your's?

Yes the Conexant sits on this chipset so I have it auto configuring the nosnoop offset 79 to 00 now. What I meant was on those ICH7 and ICH8 chipsets the nosnoop bit is on by default (set to 08 at offset 79) but audio still plays without setting it to 00. Not sure why audio works while it is set to 08 which is nosnoop enabled. On 0F04 and 1E20 they are set to 08 at offset 79 by default but I must clear them to 00 for sound to work.

On 4/14/2026 at 4:17 AM, deomsh said:

I don't like setting VolumeWidget/ OutputWidget 'overrules' any SET Verb in HDAICOUT.HDA regarding to these.

Yes I have completely removed volume widget/output widget/sleeping widget from HDA2 so it can't conflict with the auto configuration that the new widget parser now does.

On 4/14/2026 at 4:17 AM, deomsh said:

So maybe if you found 'Speaker' with 'No physical port' you can try?

If Chan Count LSB = 00 on all output pin widgets then assume only mono output is capable for that codec. I am yet to find one.

My rules for locating the correct speaker out pin are as follows:

How To Locate Correct Pin Widget (for output to internal speaker):
Chan Count LSB = 01 (2 channels for stereo - from widget caps F00-09 Bit 0),
Port Connectivity = 02 (Fixed function device - from config default F1C-00 Bits 30:31),
Default Device = 01 (Speaker - from config default F1C-00 Bits 20:23),
Connection Type = 07 (Other Analog - from config default F1C Bits 16:19) OR 03 (ATAPI Internal - Lenovo S10-3 does this)

On 4/14/2026 at 4:17 AM, deomsh said:

Better try a more conservative setting: 'MinTimeSlice=40' because of better multitasking.

Excellent I implemented MinTimeSlice=10 to be sure. Also followed all of the other stabilizing methods you listed in the earlier pages of the thread including removing HDATSR and manually implementing [BUSMASTER] settings according to your specs and all is stable.

On 4/14/2026 at 4:17 AM, deomsh said:

So the 32-bits (or 24-bits?) => 16-bits is working with your version?

Yes working cleanly now. 48Khz wav file 16bit playing in Foobar with codec stream configuration set to 44.1Khz, so Foobar is successfully 'crossing the streams'. Also DXDIAG all sounds good.

On 4/14/2026 at 4:17 AM, deomsh said:

P.S. your 'hack' for HDAICOUT.HDA above 256 lines is working in Windows 3.1 too. The culprit was een old version of HDA2.DLL in the root of my C-drive, loading first. 

Oh that is great news! I had no idea HDA2.DLL would have any effect from the C-drive root..? Good to watch out for in future.

[isolar]

Some more progress today, I have implemented your controller ID data into genhda.inf and it now detects the HDA Controllers correctly for device manager naming.

I noticed HDA Sound 2017-2022 in the multimedia settings was persisting even though I updated it to 2017-2026.. so I ran 'build all' again in Delphi after clearing out all of the old files left over from past compiles. During 'build all' syntax error appeared in unit2.pas at the line:

function Mmsystem_DriverCallback(dwCallback:longint;uflags:word;
    hdevice:word;uMessage:word;dwUser,lparam1,lparam2:longint):boolean; external 'mmsystem' name 'DriverCallback';

fixed by declaring as far:

function Mmsystem_DriverCallback(dwCallback:longint;uflags:word;
    hdevice:word;uMessage:word;dwUser,lparam1,lparam2:longint):boolean; far; external 'mmsystem' name 'DriverCallback';

This function appears in multiple files and needed to patch for all of them during build all. After that fix everything compiles correctly and Multimedia settings now shows HDA Sound 2017-2026. I had to add 1 line to genhda.inf to remove the registry key for wavehda which stores the old settings if not deleted upon driver uninstall. HKLM,"System\CurrentControlSet\Control\wave\wavehda" in the [HDA2.DelReg] section.

Also changed the message in the multimedia settings for the audio controller - will try to get this section to show the audio codec as you suggested.

More to come!