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

[deomsh]

@MisutaaUrufu

For now I will give a response to your posts and some suggestions.

21 hours ago, MisutaaUrufu said:

Both act like it works, but with "quirks"; DOS mode will just be like "yeah sound is playing" when I tried test utilities from another form thread on the driver, whereas in Windows, the media player and the system sounds window will get "stuck" in a playing state, but the progress scrubber will not move (in media player) and it must be "stopped" manually. — But there's no sound at all when this happens.

MS-DOS has no quirks, 'PCI_quirks' are used in Linux-code to have a defined name for a PCI related problem. In case of HD-audio controllers quirks are for instance related to the so called "No Snoop"-mechanism.

Did you try the version in Mplayer_dos.zip too?

Besides: none of the four MS-DOS players I tested gave sound in Virtual Box 6.0 (Judas21c, Judas21d and two versions of Mplayer mentioned in this thread).

21 hours ago, MisutaaUrufu said:

I've tried various adjustments, deleting HDAICOUT.HDA (after backing it up of course), changing values in HDAcfg. I'm not sure if there's something I'm missing, if ICH10 is too new for this driver, or if Windows 95 has a weird quirk (everywhere I've read it seems like people have tried this with Windows 3.1 or Windows 98SE, and have assumed it will work with 95 as a result.).

Here's my HDAcfg, for reference:

HDAICOUT.HDA is ment to sent specific verbs if the standard verbs sent by the driver (HDA2.DLL) fails.

As you can see in HDACFG.INI your Codec isn't identified yet. CODEC_VID=$1AB8 CODEC_DID=$0001 is not a known HDA-codec. Maybe a modem? Unless the codec is correctly identified, nothing can be done. In the first attachment of your later post the codec is identified as VendorID=6840 DeviceID=1. Still unknown to me, maybe a fake id. for Parallel's Virtual HDA-codec.

Although HDA2.DLL is ment for Win.3x only, it's tested on Windows 98SE and Windows ME, I can't remember if I tested Windows 95/Windows98FE, but it's is likely to work if their are no Memory/IRQ-conflicts.

21 hours ago, MisutaaUrufu said:

I was able to find an archived version of the 64bit installer of HDAUtil via a url punched into wayback from the extracted contents of the 32bit MSI. I have HDAUtil if this helps.

Can you provide a link to the download page? In the past I used a 32 bits program, only compatible with Windows 7. I need it to open the xml-attachment in your other post.

21 hours ago, MisutaaUrufu said:

Would anyone be able to point me in the direction of troubleshooting here? Like I said, this falls out of my area of expertise.

I am not an expert either, in my opinion nothing can be done on the codec-level until the codec is correctly identified in HDACFG.INI.

17 hours ago, MisutaaUrufu said:

Setting Verbinterface to $0 prevents the desktop and taskbar from displaying; Windows hangs at my wallpaper, requiring a forced reboot.

 This means that the so called "Immediate Command" communication-mechanism is not working with HDA2.DLL in combination with your HDA-controller.

17 hours ago, MisutaaUrufu said:

Changing the timing values to 250+, and setting the pcipatchB to various values, so far, has not worked.

Try timings 1000 or 2000 (milli-second!), but I doubt things will change.

Settings in pcipatchB will only work if there are RW (Read/Write) registers in your Parallel's VM-HDA-controller PCI-register. I am afraid that's unlikely. I have only tested Virtual Box: their VM-HDA-controller PCI-register is Read-only, so al values are fixed. You can try to write to the registers from Windows with INTELHDA.EXE. Just go to the pci-tab. If you double-click on a register, a dialog will be opened to give new values. If they actually do NOT change, that register is Read-only. You can try all the (four digits) register-entries.

But first I would suggest to disable temporarily ALL devices, especially Network, except the bare minimum. Be sure in Sound the HDA is selected. In the User Manual of Parallel 16 I found there is an option for AC'97 too. Monitor HDALOG.TXT if lines containing F0 give any other response.

For now I will not repond to your settings on the codec level. I think you will now understand why.

Edited August 28, 2020 by deomsh
Corrections

[deomsh]

9 hours ago, sweaterfish said:

Indeed I have.

Good work! I will start writing a Thinkpad X61 specific version of HDAICOUT.HDA

9 hours ago, sweaterfish said:

However, I'm still in the dark about what all this stuff is about, so I'm finding the process sort of frustrating. Could I ask you to take a minute and explain what the goal of the HDAICOUT.HDA file is? Like what is it attempting to do exactly? Same for the pcipatchb lines in the HDAcfg.ini file. What is the point of this line and where are you getting the values you're suggesting to use?

I understand your frustation, if you allow me a personal note: you can find my own Quest regarding HD-Audio here: https://web.archive.org/web/20180318132454/http://win3x.conforums.com/index.cgi?board=Pascal&action=display&num=1502071336 (I saw Watler recently published the first 8 pages of the Conforum-posts in a zip: http://turkeys4me.byethost4.com/files/?i=1)

The driver HDA2.DLL has it's own set of verbs to identify the codec and give the codec some basic configuration. The goal of HDAICOUT.HDA is to sent specific SET-verbs to the codec if the general verbs are 'not enough'. You can find many (all?) verbs in a box under the nodules-Tab of INTELHDA.EXE.

Advanced HDA-drivers, like the driver of the Linux ALSA project, have widget parsers onboard to identify all widgets and set (semi-)automatic a working configuration. Still these projects have many codec/board specific problems to overcome. HDA2.DLL has no widget parser. INTELHDA.EXE has one (as you already found out using the widgets Tab), but will report only.

For testing purposes you can sent individual verbs to the codec, with the 'Immediate Command'-interface under the jds-Tab, or with the CORB-interface under the CORB-Tab. Afterwards they can be copied to HDAICOUT.HDA.

You can try yourself (only the CORB-Tab will work in case of your HDA-controller). In a nutshell (you gave me a minute...): click button 'Corb reset', check the box 'Use Corb for Verbs', type $000F0000 in the box directly right of button 'CorbWrite' and click that button. The codec response you're supposed to get in the big box beneath button 'View Corb' should be the same as in HDALOG.TXT! Before a next verb, first click "Corb reset'. To get special values I always search first in the codec-datasheet (if available), in combination with Linux-sources for bug reports (ALSA, Hackintosh, InsanelyMac, Kolibri, FreeBSD and others). Most sources doesn't give full verbs, but only parts of them (their drivers work in that way, almost impossible to read for a non-programmer like me).

On the level of the HDA-controller sometimes a patch is needed for HDA2.DLL to any make communication with the codec possible at all (@bmw's stage) or otherwise. One 8-bits register can be set to a certain hexadecimal value with pcipatchB. There are several way's to get PCI HDA-controller register values. First get access to the specific datasheet if available - scroll to the HDA-registers and start reading (and counting, the binary bit-values have to be converted to a hexadecimal value), and search for PCI_quirks in Linux sources. Another approach is to try MS-DOS players and if they are providing sound: read out the controller registers for changes (experimental approach).

Be aware I have only 'worked' with a dozen HD-audio motherboards or so, and counted with direct access only with five.

Edited August 28, 2020 by deomsh
Corrections, better description of Corb-Tab

[MisutaaUrufu]

5 hours ago, deomsh said:

@MisutaaUrufu

MS-DOS has no quirks, 'PCI_quirks' are used in Linux-code to have a defined name for a PCI related problem. In case of HD-audio controllers quirks are for instance related to the so called "No Snoop"-mechanism.

Did you try the version in Mplayer_dos.zip too?

Besides: none of the four MS-DOS players I tested gave sound in Virtual Box 6.0 (Judas21c, Judas21d and two versions of Mplayer mentioned in this thread).

I meant "quirks" as in the behavior was odd and unexpected; I didn't mean it in the technical sense, my apologies.

I didn't try mplayer, no, but considering you mention that none of them gave sound through DOS in Virtual Box, I imagine the same would go here as well.

5 hours ago, deomsh said:

@MisutaaUrufu

HDAICOUT.HDA is ment to sent specific verbs if the standard verbs sent by the driver (HDA2.DLL) fails.

As you can see in HDACFG.INI your Codec isn't identified yet. CODEC_VID=$1AB8 CODEC_DID=$0001 is not a known HDA-codec. Maybe a modem? Unless the codec is correctly identified, nothing can be done. In the first attachment of your later post the codec is identified as VendorID=6840 DeviceID=1. Still unknown to me, maybe a fake id. for Parallel's Virtual HDA-codec.

Although HDA2.DLL is ment for Win.3x only, it's tested on Windows 98SE and Windows ME, I can't remember if I tested Windows 95/Windows98FE, but it's is likely to work if their are no Memory/IRQ-conflicts.

That is the correct codec, as far as I can tell.. Vendor ID 1AB8 is identified as Parallels Desktop, and their other simulated hardware devices follow a similar convention. Likewise, changing the codec value gets reset on next boot by the TSR anyhow (it's blocked out with Fs before the driver is loaded by Windows). There is no "modem" attached to the virtual machine; only a simulated PCIe ethernet card (a Realtek model).

The parallels log file for the virtual machine indicates that the HDA device is being activated, but that the VM is making an invalid read at an incorrect address. — If I let it run for too long it'll actually build up a hefty log file just filled with the "invalid read" lines. (It reached 9GB at one point. 9GB of just that one line.) — I'm thinking this may be concerned with HDAICOUT and the widget addresses in HDA configuration.

The odd thing is the number output in the INI by HDAUtil for the Subsystem ID is different than the one populated in the HDA configuration by the TSR. But changing it has no effect as the TSR resets the value on boot.

5 hours ago, deomsh said:

@MisutaaUrufu

Can you provide a link to the download page? In the past I used a 32 bits program, only compatible with Windows 7. I need it to open the xml-attachment in your other post.

I can do you one better. Seeing as the download page had to be accessed in convoluted fashion via the wayback machine on the internet archive, I took the liberty of uploading the installer directly to the archive itself for ease of access:

Microsoft High Definition Audio Utility 64-bit : Internet Archive

5 hours ago, deomsh said:

@MisutaaUrufu

I am not an expert either, in my opinion nothing can be done on the codec-level until the codec is correctly identified in HDACFG.INI.

 This means that the so called "Immediate Command" communication-mechanism is not working with HDA2.DLL in combination with your HDA-controller.

Try timings 1000 or 2000 (milli-second!), but I doubt things will change.

Settings in pcipatchB will only work if there are RW (Read/Write) registers in your Parallel's VM-HDA-controller PCI-register. I am afraid that's unlikely. I have only tested Virtual Box: their VM-HDA-controller PCI-register is Read-only, so al values are fixed. You can try to write to the registers from Windows with INTELHDA.EXE. Just go to the pci-tab. If you double-click on a register, a dialog will be opened to give new values. If they actually do NOT change, that register is Read-only. You can try all the (four digits) register-entries.

But first I would suggest to disable temporarily ALL devices, especially Network, except the bare minimum. Be sure in Sound the HDA is selected. Monitor HDALOG.TXT if lines containing F0 give any other response.

You seem to know a lot more than I do on this particular topic though.

I will try removing the network card from the VM and see if that has any effect later on, but I highly doubt that will change anything.

5 hours ago, deomsh said:

@MisutaaUrufu

In the User Manual of Parallel 16 I found there is an option for AC'97 too.

Unfortunately AC'97 support no longer works in Windows 95 on Parallels. They deprecated support for "legacy" systems a few years back, so whilst the VM does simulate an AC'97, it's behavior has changed from how it worked when Windows 95 was an actively supported configuration. They no longer provide sound drivers either (only video). I've tried numerous generic drivers with no luck; they install, and Windows says they work, but no sound is passed to the main OS, and the parallels log just spits out "[pcm_out] reset inside DMA" every once in a while if audio is "playing" in the VM. — This log output is infrequent, compared to the HDA log output.

This is why I am trying to get the HDA2.dll driver working in the first place. AC'97 support is broken, but I at the very least can confirm that some sort of interaction with the HDA controller is happening (the soft crackle through earbuds/headphones when audio attempts to play). In theory, if I could get the configuration correct, I could get audio out. However, it is sounding as if I may need an entirely custom configuration to communicate with Parallels' implementation of HD Audio.

Off topic: Ironically, Parallels provides an OS/2 driver for sound. It's just Windows 2000 and earlier they don't provide.

Edited August 28, 2020 by MisutaaUrufu
Clarification

[deomsh]

4 hours ago, MisutaaUrufu said:

I didn't try mplayer, no, but considering you mention that none of them gave sound through DOS in Virtual Box, I imagine the same would go here as well.

@MisutaaUrufu Testing is the only way to get somewhere with this driver, mplayer will take only a quarter to half an hour. I saw you´re a new member: don´t forget your input can be relevant for other readers!

4 hours ago, MisutaaUrufu said:

Likewise, changing the codec value gets reset on next boot by the TSR anyhow (it's blocked out with Fs before the driver is loaded by Windows).

I don´t understand, what do you mean with 'TSR' and which setting you changed exactly?

4 hours ago, MisutaaUrufu said:

There is no "modem" attached to the virtual machine; only a simulated PCIe ethernet card (a Realtek model).

No modem = GOOD In the Parallel's User Manual I found three different Network configurations. So you may have four possibilities, included switching Network off.

4 hours ago, MisutaaUrufu said:

I can do you one better. Seeing as the download page had to be accessed in convoluted fashion via the wayback machine on the internet archive, I took the liberty of uploading the installer directly to the archive itself for ease of access:

Thanks for the link. This is the 64-bit version, but as far I as know not compatible with Windows 10. Importing of your xml gives me an error only, importing the ini gives a widget-list that makes ABSOLUTE no sense for a codec. Better try Windows 7 with the High Definition Audio Utility, I believe you have one month free trial with Win7.

4 hours ago, MisutaaUrufu said:

I will try removing the network card from the VM and see if that has any effect later on, but I highly doubt that will change anything.

Experimenting is partly a blind process, so just try please.

4 hours ago, MisutaaUrufu said:

Unfortunately AC'97 support no longer works in Windows 95 on Parallels. They deprecated support for "legacy" systems a few years back, so whilst the VM does simulate an AC'97, it's behavior has changed from how it worked when Windows 95 was an actively supported configuration. They no longer provide sound drivers either (only video). I've tried numerous generic drivers with no luck; they install, and Windows says they work, but no sound is passed to the main OS

I have been reading some Parallel 9x Forum-threads, they all complain about having no sound. Watler made an Win3x AC'97 driver too: Intel 82801AA/DB ICH AC'97 Sound Driver 10 (I have never tried it, but some people on the internet liked it, don't remember exactly). It's here: http://turkeys4me.byethost4.com/programs/ 

4 hours ago, MisutaaUrufu said:

This is why I am trying to get the HDA2.dll driver working in the first place. AC'97 support is broken, but I at the very least can confirm that some sort of interaction with the HDA controller is happening (the soft crackle through earbuds/headphones when audio attempts to play). In theory, if I could get the configuration correct, I could get audio out. However, it is sounding as if I may need an entirely custom configuration to communicate with Parallels' implementation of HD Audio.

If HDA2.DLL is working you should hear about three medium-loud click's/pops.

About that 'entirely custom configuration': the source code is included in HDADRV9J.7z (Delphi 2 ).

If you want to test Watler's INTELHDA.EXE, it's inside AHDA17M (download is actually AHDA17O.7Z) on: http://turkeys4me.byethost4.com/files/

[deomsh]

On 8/28/2020 at 1:46 PM, deomsh said:

Settings in pcipatchB will only work if there are RW (Read/Write) registers in your Parallel's VM-HDA-controller PCI-register. I am afraid that's unlikely. I have only tested Virtual Box: their VM-HDA-controller PCI-register is Read-only, so al values are fixed. You can try to write to the registers from Windows with INTELHDA.EXE. Just go to the pci-tab. If you double-click on a register, a dialog will be opened to give new values. If they actually do NOT change, that register is Read-only. You can try all the (four digits) register-entries.

@MisutaaUrufu Today I tested if I could write to some PCI registers of VBOX 6.0.18 with INTELHDA.EXE. It was possible, new values even survived a VBOX reset. So I think the earlier tests I referred to where on an earlier 32-bits version, or my memory was mistaken altogether.

22 hours ago, deomsh said:

Testing is the only way to get somewhere with this driver, mplayer will take only a quarter to half an hour.

Watler's Win.3x HDA driver can be used in VBOX (contribution of @UCyborg). Today I made a small discovery: after Reboot to MS-DOS, some MS-DOS players gave sound . Both mplayer versions remain silent, but Judas21C and Judas21D happily played their XM-files WITH SOUND! I think HDA2.DLL or HDAICOUT.HDA provided some verbs Judas21C/D didn't sent. Without loading HDA2.DLL in Windows, Reboot to MS-DOS gave no sound with Judas21C/D.

With the MS-DOS-version of Craig Hart's PCI+AGP Sniffer I compared the HDA-controller registers in all situations, but they where all exactly the same, so no (HDA2.DLL-internal) PCI_quirks involved.

So maybe Parallel's registers have RW-registers too ready for testing.

Edited August 29, 2020 by deomsh
Typo's

[deomsh]

Error, to be removed

Edited August 29, 2020 by deomsh
Error

[deomsh]

@sweaterfish I made a first draft of a Thinkpad X61 specific version of HDAICOUT.HDA so just rename and put in your Windows folder. It's partly based on a Linux plugin for your codec brand. https://review.clip-os.org/plugins/gitiles/clipos/src_external_linux/+/21949f00a022e090a7e8bc9a01dfca88273c6146/sound/pci/hda/patch_analog.c

In this document I found also:

/* Lenovo Thinkpad T61/X61 */
   SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo Thinkpad", AD1984_THINKPAD),

I can't find the exact correspondence with the HDA controller registers, but pcipatchB=$17AA is worth a try, of course first without HDAICOUT.HDA. 0x17aa seemed to be subsystem vendor id. It's in your picture of the HDA controller registers too (W16).

Now you have three two pcipatchB testing possibilities together with HDAICOUT.HDA: $0000, $7900 and $17AA. Combined with three different modems settings gives nine six. Best start with your latest discovery (physical modem removed, but switched on in BIOS).

Please upload afterwards HDACFG.INI, HDALOG.TXT and HDAICIN.TXT and report.

Thinkpad_X61_Debug_HDAICOUT.HDA

Edited August 29, 2020 by deomsh
Correction

[sweaterfish]

@Deomsh

Thanks for your explanations and the link to the ALSA source. I think it's beginning to make more sense and now at least I understand the format of the lines in the HDAICOUT.HDA file, addressing widgets with verbs and an object to the verb, and how this configures the sound codec. Still plenty of mysteries, but I can understand some things at least.

I tested the X61 HDAICOUT.HDA file and while there is still no sound, there are a few differences. First, it no longer seems to matter whether I have the modem enabled or disabled in BIOS or installed or uninstalled in the system. All combinations give exactly the same results, with a properly populated HDAcfg.ini and the same responses in HDAICIN.TXT.

Second, there's some more promising crackles during boot, sounding very much like an audio connection being made. I confirmed that this is due to including the AC_VERB_SET_EAPD_BTLENABLE verb, which I gather is a peculiarity of this Thinkpad board.

I did test with and without setting pcipatchB=$7900 and there was no effect. All the log files are identical, so I'm just posting the ones with pcipatch=$0000.

I also tried modifying your HDAICOUT.HDA to set up DAC_1 and mixer $0A since that seems to be the one they chose to use in Linux for whatever reason. No difference, though.

The only thing I don't understand in the HDAICIN.TXT is the AC_VERB_GET_POWER_STATE responses and why some of them don't seem to change. After the system is up, if I check with INTELHDA.EXE, the widgets that returned 0x30 at boot are all returning 0x00. I can't find info on what 0x30 means anyway, though, so maybe it's not important and it's only the last bit that matters.

HDAICIN.0000.txtHDALOG.0000.txtHDAcfg.0000.txt

[deomsh]

@sweaterfish Good testing, strange your HDACFG.INI is now populating in all modem variants.

On 8/31/2020 at 6:27 AM, sweaterfish said:

Second, there's some more promising crackles during boot, sounding very much like an audio connection being made. I confirmed that this is due to including the AC_VERB_SET_EAPD_BTLENABLE verb, which I gather is a peculiarity of this Thinkpad board.

Please describe the crackles in detail: are there three during booting Windows, or when starting an audio file in a media player? Further: EAPD is a laptop ´thing´, but I searched for Thinkpad X61 only.

On 8/31/2020 at 6:27 AM, sweaterfish said:

I did test with and without setting pcipatchB=$7900 and there was no effect. All the log files are identical, so I'm just posting the ones with pcipatch=$0000.

Keep both possibilities in all your tests to be sure.

On 8/31/2020 at 6:27 AM, sweaterfish said:

I also tried modifying your HDAICOUT.HDA to set up DAC_1 and mixer $0A since that seems to be the one they chose to use in Linux for whatever reason. No difference, though.

I do not understand why Takashi Iwai wants to use DAC_1, but there is a sidenote (typo is made by him):
"* FIXME:
* For simplicity, we share the single DAC for both HP and line-outs
* right now. The inidividual playbacks could be easily implemented,
* but no build-up framework is given, so far."

Be aware the default connection of Mixer 07 is to DAC-widget 03, Mixer 0A to DAC-widget 04. But there appears to be Selector widget 22 who can set Mixer 07 to DAC-widget 04. It's in the datasheet, but in this AlsaInfo.txt more in detail. You only have to 'read' the Codec information (compare with output of various buttons of INTELHDA.EXE's widget Tab): http://launchpadlibrarian.net/176533849/AlsaInfo.txt

On 8/31/2020 at 6:27 AM, sweaterfish said:

The only thing I don't understand in the HDAICIN.TXT is the AC_VERB_GET_POWER_STATE responses and why some of them don't seem to change. After the system is up, if I check with INTELHDA.EXE, the widgets that returned 0x30 at boot are all returning 0x00. I can't find info on what 0x30 means anyway, though, so maybe it's not important and it's only the last bit that matters.

Yeah, last hexadecimal value (four bits) should be zero for power state D0 (fully on). That's our only concern here. The SET-verb can only set one of the power states, but the GET-verb can provide more states for 'software' (more details in Intel' High Definition Audio Specification page 151-159). I am not sure about the values of INTELHDA.EXE, a version of HDA2.DLL is part of this program.

A few things for further I experiments for now:
1) Don't forget to test if pushing the physical volume buttons gives any difference.
2) First I'd like like to see HDAICIN.TXT after commenting out the first to verb-lines in the 'debug' version HDAICOUT.HDA I made you (commenting out with a semicolon). So without Codec Reset, but with a full new boot (first fully switching off the machine for a minute or two).
3) Change lines in HDAICOUT.HDA one by one, Reboot to MS-DOS/Exit to Windows in between is much faster, you won't lose your other codec-settings. If the GET-verbs give same output before, and after a SET-verb, that SET-verb is unnecessary. Comment those verbs out, they will not be shown up in HDAICIN.TXT anymore. Editing using 'Run' is fastest in my opinion (Ctrl+Esc => Run => C:\Windows\Notepad HDAICOUT.HDA and same procedure for HDACFG.INI).

Edited September 1, 2020 by deomsh
Typo's

[sweaterfish]

We got 'em! I'm here listening to MP3s on my X61 in Windows 98SE right now! This is awesome. Thanks so much, deomsh!

The issue seems to have been that the AD1984 cannot handle volume set to the mx value and just shuts down the sound. I haven't tested the upper limit yet, but even the default of 0x27 is a bit too loud. I had actually tried changing that volume value in the HDAICOUT.HDA already, but there was still a separate volume setting in HDAcfg.ini causing the problem. Simply not setting a volume in HDAICOUT.HDA and setting it at $42004200 in HDAcfg.ini is working great, though.

I also found that DAC_1 (widget $04) has to be used to get audio from the internal speakers. This makes sense now that I know what to look for in the AD1984 datasheet. Port D (line out/speakers) is only connected to $04 while port A (headphones) is connected to $22 which selects between either $03 or $04.

A custom HDAICOUT.HDA is still needed, but with only a few verbs.

• unmute input on port A's mixer
• unmute output on port A
• select DAC_1 for port A
• unmute input on port D's mixer
• unmute output on port D
• enable EAPD on port D

I think HDA2.DLL itself  powers on and sets up the required DAC, so no verbs for $04 seem to be necessary in HDAICOUT.HDA. I'm attaching my working HDAICOUT.HDA and HDAcfg.ini files here. I left all the unneeded lines in HDAICOUT.HDA in case they're needed for future troubleshooting.

Thanks again for all your help and explanations. This has made my day!

HDAcfg.X61.ini HDAICOUT.X61.HDA

[deomsh]

@sweaterfish Congratulations, you deserve it!

Just for the record:

• Was pushing the physical volume buttons needed?
• Was commenting out the 'Codec reset'-verbs REALLY needed?
• Are Headphones/Speaker both working, and is the speaker muted if you plugin headphones?
• Is it possible to change volume with WAVEOUT.EXE?

Further: would you be so kind to upload HDALOG.TXT and HDAICIN.TXT, so I can see what's going on myself? Could be useful for future troubleshooting of other laptops (I don't have access to laptops with High Definition Audio codecs, although there are a few in my reach - I possess no admin rights whatever on these machines, can't even boot from USB  ).

Edited September 1, 2020 by deomsh
Typo

[sweaterfish]

12 hours ago, deomsh said:

Was pushing the physical volume buttons needed?

No, and in fact the physical volume buttons don't work unfortunately. This is odd because I always thought they were hardware controls, not software, but I guess I'm wrong. The mute button that's alongside them still works, though, and when the system is muted pressing volume up or down (or mute again) will bring the sound back, but they just won't make it louder or quieter.

 

Quote

Was commenting out the 'Codec reset'-verbs REALLY needed?

No, I only removed it from my trimmed down HDAICOUT.HDA because it didn't seem to be necessary, but audio still works fine with it in. Same for all the other verbs I commented out. None of them break the audio, but they don't seem to have any effect. Let me know if you think there's some reasons to include some of them, though. I haven't tested everything yet.

 

Quote

Are Headphones/Speaker both working, and is the speaker muted if you plugin headphones?

Yes, that's all working just as expected. I did spend some time trying to get the PC Speaker (Beep) working again (it works without the HDA2.DLL driver installed, like I mentioned before), but couldn't seem to figure it out. From what could gather by looking at other AD datasheets, it seems like there's two separate Beep capabilities, one is a direct Digital Beep generator ($10) and the other is an analog input ($1A) that can be connected to a port. I think the second one is the traditional PC Speaker that's controlled by the motherboard, so I tried setting up a stream by unmuting and setting volume to inputs and outputs as seemed appropriate, but never got any beeps from it. I probably won't spend any mor etime on it since I basically realized that any game I'd want to play that relies on the PC Speaker, is better off being run from pure DOS without starting Windows anyway, so it's not really an issue.

 

Quote

Is it possible to change volume with WAVEOUT.EXE?

Yes, WAVEOUT.EXE works and now that you mention it, that's a quick way to test the volume limit on the device. I tried it and audio seems to stop playing at $CE00. However, there's no actual change in volume once I move the slider above $4F00 (which is equivalent to the default 0x27) even though audio still plays. So it seems like the default volume setting at power up is already the actual maximum. $0000 is indeed silent, so all the actual volume control is in the range between $0000 and $4F00.

 

Quote

Further: would you be so kind to upload HDALOG.TXT and HDAICIN.TXT, so I can see what's going on myself?

Yes, attached. This is with all the verbs uncommented so that you can see everything working. All the verbs seem to work just the same even if some of the others are commented out. I set the wait timers so low in my working HDAcfg.ini (there seems to be no issues at $20) that the responses in my HDAICIN.TXT become mostly zeros, so the file I'm attaching is with wait1 and wait2 set back up to $100.

 

Quote

Could be useful for future troubleshooting of other laptops (I don't have access to laptops with High Definition Audio codecs, although there are a few in my reach - I possess no admin rights whatever on these machines, can't even boot from USB  ).

As far as I can tell, the same HDAICOUT.HDA that works on my X61 should work with little or no change on other Thinkpads from the same generation, like the T61, R61, etc. These are pretty popular models with Thinkpadders, so I'll spread the word and as long as I'm not the only one wanting to run Windows 98SE on a Thinkpad, I bet there'll probably be some testers for those models.

HDAICIN.ALL.TXT HDALOG.ALL.TXT

[deomsh]

@sweaterfish Thanks for your comments.

I made a simple drawing of the Functional Block Diagram for AD1984. Left I added the basic HDAICOUT.HDA with some possible extensions. I'm not fully sure about the Input Mixer connections, I believe there is an error in the datasheet. The original scan was 6 MB, so 256KB will not give the same quality anymore.

Would you do me the favor to test the basic part of HDAICOUT.HDA with all three widgets in HDACFG.INI set to $FF? I want to know if the verbs in HDAICOUT.HDA can control everything (already tested on my H61 board and in Virtual Box). If sound is okay, I also would like to know if WAVEOUT.EXE is working without the right VolumeWidget in HDACFG.INI.

[sweaterfish]

Yep, setting the widgets to $FF in HDAcfg.ini and powering them on and configuring them in HDAICOUT.HDA does produce audio. WAVEOUT.EXE does not control the volume, though. Sound quality is low with the settings you provided, but changing $00420014 > $00424014 gives regular quality. Line $011707C0 isn't needed since the default of 0x40 seems to work properly, though I do see that the Linux source sometimes sets it to 0xC0 and that works as well.

Your PC Beep code is also working for me. I was just not powering on the Analog Mixer ($19), which does seem to be required. So the PC Speaker is working fine now. I assume similar code would allow other inputs to at least be passed through. Would just connecting them to an ADC Selector and powering on the corresponding ADC allow for recording? I haven't tested anything with that yet.

I hoped that having the PC Speaker working would solve a stability issue I've had where keyboard key rollovers sometimes cause Windows to crash (ocassionally with the message "Runtime error 202 at 0003:01BE"). It does not happen if HDA2.DLL isn't installed and key rollovers are supposed to make the speaker beep, so I thought the non-working beeper might be causing the problem, but still happens even when the beep is working. It only crashes when you do a bunch of rollovers in a row, though, so it pretty much won't happen unless you're trying to make it happen.

[deomsh]

@sweaterfish Thanks for testing.

On 9/4/2020 at 3:11 AM, sweaterfish said:

WAVEOUT.EXE does not control the volume, though.

Setting only VolumeWidget in HDACFG.INI to $04 should give WAVEOUT.EXE full control.

On 9/4/2020 at 3:11 AM, sweaterfish said:

Sound quality is low with the settings you provided, but changing $00420014 > $00424014 gives regular quality

So the default of 48kHz is NOT the best choice. All in all the standard Output verbs sent by HDA2.DLL are the best choice. In that case their is no reason to maintain the $004-verbs in HDAICOUT.HDA and the Widget lines in HDACFG.INI can set to their original $04-values.

On 9/4/2020 at 3:11 AM, sweaterfish said:

Line $011707C0 isn't needed since the default of 0x40 seems to work properly, though I do see that the Linux source sometimes sets it to 0xC0 and that works as well.

Not only sound quality matters, the $011707C0 verbs is ment to activate the headphone amplifier needed to drive a low-impedance device (see the AD1984 datasheet). I don't know if their are any risks involved without, but that's all yours. I am not liable for it, I even never advocated use of HDA2.DLL!

On my ALC662 codec (Realtek) enabling the headphone amplifier introduces noise, so I use 70740 only.

On 9/4/2020 at 3:11 AM, sweaterfish said:

Your PC Beep code is also working for me. I was just not powering on the Analog Mixer ($19), which does seem to be required. So the PC Speaker is working fine now. I assume similar code would allow other inputs to at least be passed through.

Good!

In my drawing the verbs for Aux are included (CD/DVD - not standard on Thinkpad X61 I believe, but an extension for the slim Ultrabay). On my system analog CD/DVD-audio redirected through the codec sounds much better than digital CD/DVD-audio.

On 9/4/2020 at 3:11 AM, sweaterfish said:

Would just connecting them to an ADC Selector and powering on the corresponding ADC allow for recording? I haven't tested anything with that yet.

No, HDA2.DLL is playback-only by design. Although ADC can be enabled on the codec level and will be sent to the Azalia Link, nothing else will happen.

On 9/4/2020 at 3:11 AM, sweaterfish said:

I hoped that having the PC Speaker working would solve a stability issue I've had where keyboard key rollovers sometimes cause Windows to crash (ocassionally with the message "Runtime error 202 at 0003:01BE"). It does not happen if HDA2.DLL isn't installed and key rollovers are supposed to make the speaker beep, so I thought the non-working beeper might be causing the problem, but still happens even when the beep is working. It only crashes when you do a bunch of rollovers in a row, though, so it pretty much won't happen unless you're trying to make it happen.

The Runtime error you mentioned is the main reason to be very careful using HDA2.DLL. It can have very bad consequences. After a soft/hard reset Windows sometimes will use auto-scandisk. ALWAYS let the program finish and watch carefully SCANDISK.LOG afterwards. In general I don't agree switching Autoscan off in MSDOS.SYS.  Scandisk is your best friend, but like best friends his comings and goings are not always desirable.

Stability issues are reported while copying files together with audio playback. Also during simultaneous downloading of files and running DOS-boxes (the Windows command-line CONAGENT.EXE is involved too). But these issues are also dependent in de video card used!

Know stability measures are: setting SYSTEM.INI [vache] MaxFileCache=1024 AND MinFileCache=1024, set [386Enh] MinTimeSlice=100. Also using SMARTDRV.EXE /X /L /V /B:57344 can be helpful (and speeds up file reading operations to compensate for the ultra low vcache setting - by design SMARTDRV.EXE can only be used on partitions 128 G(i)B max).

During software installations / big copy-operations I always switch HDA2.DLL off with a semicolon before the HDA2.DLL wave(hda)-entrance in SYSTEM.INI and reboot Windows.

Edited September 9, 2020 by deomsh
Typo