isolar Posted February 24 Posted February 24 HDAcfg Settings) Okay interesting results with using my codec selector version of HDA2.DLL, turning off HDAICOUT, Enabling PCIPatchB=$7900 (specific for this PCI device) and setting sleepingwidget/volumewidget/outputwidget correctly. My sleepingwidget can be anything as AFG and DAC nodes are already powered at reset (and to note the HDALOG shows AFG power on 705 sent automatically directly after F00 verbs - therefore setting sleeping widget to $02 means BOTH AFG and DAC if DAC is $02 to power on if that is required - no harm in leaving this set), my volume widget and output widget are both set to $02 DAC where it sets stream as 44.1kHz, 16 bit, 2ch - 0+1, stream 1, BUT automatically sets volume to 7F. I note your log above reports volume set to 32 so unsure if this is a codec specific setting it detects or is hard coded in your version of HDADRV? ... I will investigate. Results) I receive ALMOST the same HDALOG results as you posted above. From your responses I ascertain you have sleepingwidget/volumewidget/outputwidget all set to $02. Verb 707) Verb 707 with payload C0 is optimal (better than 707 40 which is output only and does not enable headphones) to enable output AND headphone on a pin widget. This is good as if there is no headphone then the headphone bit is ignored and output is enabled. This does not help with input widgets... but maybe this could be coded into it so output widgets are all set to out and input widgets set to in, payload 20? Vref settings required to be set if input is enabled. Verb 3xxx) It is unmuting all mixers and pin widgets Out Left & Right at index 0 (which can be read from the get payload bits 0 to 3) from node 0C through to 1B. If a mixer or pin widget needs input set it does not address this - maybe my idea of using 3Fxxx verb could cover this? I will investigate? The only missing verb for my codec to produce sound) Is EAPD enable verb 70C payload 02 on pin widget 14 LINEOUT. Shouldn't be too hard to add this in! Therefore this codec can potentially produce sound with no HDAICOUT file as long as HDAcfg settings are correct and the codec 0 is correctly identified. So my theory is.. if the above topics can be added to HDA2.DLL code it is entirely possible to compile a version that could work with many codecs and no HDAICOUT file. Most realtek codecs seem to use a similar audio widget path (or node range for that path) as i'm sure other vendors would do. I am interested to investigate this! Do you think this is plausible?
deomsh Posted February 24 Posted February 24 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! 1
isolar Posted February 26 Posted February 26 EAPD ADDED Small steps while learning the code. I have managed to add EAPD power on to the initial startup verbs (70C02) when no HDAICOUT.HDA is present, so it now scans all widgets from 12 to 1C (although this range can be adjusted) and attempts to set EAPD power on. A good side effect of this is that now speakers and headphones are automatically working, but not individually, always together. I think unsolicited and pin sense control the feature of muting speakers when headphones plugged in? I will investigate. This will currently not work if EAPD is inverted as you mentioned.. possible that a get verb can resolve that by analyzing the response and set accordingly. WAIT 1 & 2 SETTINGS Timer settings in hdacfg.ini are now set to 40 and all is working fast and hdalog is fine. VOLUME I changed it so volume is now set to 3F by default on volumewidget rather than 7F which is too loud. Are there any known codecs where 3F may be too low to hear? Or maybe some too loud? NOSNOOP I have located the nosnoop section and think it can be set to detect and automatically set the correct pci register byte if detected. I will investigate. There are settings for Intel, ATI and Nvidia. TO FIX: - Remove the rogue $000F0005 sent at startup. - See if duplicate stream setting and volume settings sent at initialization can be removed. - Use get verbs to determine max volume and automatically set to 80% or thereabouts. - Auto detect and set PCIPatchB if needed. - Fix the timings!! - Try one verb for volume setting 3F03F to set out and in and left and right. Currently it sets left and right individually. - Try getting microphones active and recording.
deomsh Posted February 26 Posted February 26 (edited) 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? Edited February 26 by deomsh
isolar Posted February 27 Posted February 27 8 hours ago, deomsh said: I extended my investigation up to 70 documented codecs WAHEEEYYY!! This list is impressive! I believe if we can get the PCI/VEN Id's of all of these then I believe I can set a function to split the widget initialization per codec and call the necessary NID values to get sound working using a single HDA2.DLL file for all of these.. it will take some time but my enjoyment to do this has a lot of charge. 8 hours ago, deomsh said: Inverted EAPD is luckily rather uncommon. Here are is an example: https://lxr.missinglinkelectronics.com/linux+v6.15/sound/pci/hda/patch_analog.c Thank you for this! I happen to have a laptop with AD1981HD codec so I can revisit the HDAICOUT file I made for that years ago (the 1st one I messaged you about years ago) and see if there's a way to identify if it is inverted. 8 hours ago, deomsh said: 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): Why twice? Timing related? I found a hardcoded 256 verb limit in HDA.PAS so I will try to expand that to 512 which should be able to cover an entire codec dump of necessary codecs at least for plain audio output... unsure if at all possible so stay tuned on that.. it will change the game if possible. 8 hours ago, deomsh said: 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 Yes, this is a perfect example, we can use the input and output amp caps get verbs (F000D/12) to find which step is 0dB and then set that step minus about 20% to always set a nice volume on any codec. 8 hours ago, deomsh said: Good! But try to fix documented/ tested cases only Can do, is the list you posted earlier the only known ones so far? 8 hours ago, deomsh said: - $001F0005 is still needed to populate some entry in HDACFG.INI. I tried myself to skip if NID <> 1, but I failed. Should be an easy fix - currently it is trying to apply to the root node which payload 05 does not deal with, so $001F0005 (AFG, not root) is definitely correct and not $000F0005 which it currently sends. 8 hours ago, deomsh said: Did you play 'HDA bauble poker' with your HDADRV9L already? Many many many many....many times I have poked the baubles Once I managed to hardcode index 0 on this laptop it was very useful. 8 hours ago, deomsh said: unless you ment the hardcoding of HDAICOUT.HDA in HDA.PAS? Yes my goal is to get HDA2.DLL universal without the need for HDAICOUT.HDA, but still be able to utilize HDAICOUT for any codecs not listed or not working. I think In/Out does need to be kept separate so no way around that. Keen to test anyway. 8 hours ago, deomsh said: - I am curious about 'microphone', what do you mean with 'record'? Do you want to play karaoke? I will give it a go haha! But for this purpose to get the codec as active as it was made to be.
deomsh Posted February 27 Posted February 27 (edited) 9 hours ago, isolar said: WAHEEEYYY!! This list is impressive! I believe if we can get the PCI/VEN Id's of all of these then I believe I can set a function to split the widget initialization per codec and call the necessary NID values to get sound working using a single HDA2.DLL file for all of these.. it will take some time but my enjoyment to do this has a lot of charge. 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: 9 hours ago, isolar said: Why twice? Timing related? I found a hardcoded 256 verb limit in HDA.PAS so I will try to expand that to 512 which should be able to cover an entire codec dump of necessary codecs at least for plain audio output... unsure if at all possible so stay tuned on that.. it will change the game if possible. 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 9 hours ago, isolar said: Can do, is the list you posted earlier the only known ones so far? 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. 9 hours ago, isolar said: Many many many many....many times I have poked the baubles Once I managed to hardcode index 0 on this laptop it was very useful. 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. Edited February 27 by deomsh Added P.S.
isolar Posted February 28 Posted February 28 (edited) 22 hours ago, deomsh said: P.S. About the 256 verb-limit: I believe this is HDA-Spec, see Chapters 3 & 4 of Intel's High Definition Audio Specification. Small update: 256 verb limit is now unlocked, successful base test ran with 816 verbs to send all possible F00 parameters to all widgets range from 00-32h and all responses captured in HDAICIN. My timing is still off so some readings incorrectly show $00000000, plus not sure if the error exists where it puts the response on the wrong line like I had with some earlier tests. I will investigate more and report back. My goal is create a HDAICIN response for the entire codec for all possibilities. Next step in HDA.PAS to send only necessary get verbs to necessary widgets and get full codec dump. Once I have the full dump I will send you all responses for this codec. UPDATE) 2958 verbs sent via HDAICOUT and logged with HDAICIN attached. I have started to label the HDAICIN file with verb titles and some of the results. There are definitely timing issues and some missed responses similar to the initial results. Just a test to see if possible. Next step to minimise the verbs to only the necessary widgets! HDAICIN_ALL_0280.TXT Edited February 28 by isolar Add update and attach file
deomsh Posted February 28 Posted February 28 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.
isolar Posted March 5 Posted March 5 (edited) Okay some updates I have applied. HDA2.DLL can now: -Initialize and detect audio codec correctly with correct timings (patched timing and structure of HDA_RESETCORBRIRB, CORBRIRBGET1, and JHDA_RESET FUNCTIONS) -With verb interface set to $0, wait 1 and 2 set to $0: Loads almost instantly at boot and audio is clear. No HDAICOUT.HDA required. -(currently disabled) Ask for the codec index at boot and lock on to it. -Send unlimited verbs through HDAICOUT.HDA and receive all responses with no timing issues to HDAICIN.TXT. (See latest response file below with full decode). -Automatically enable EAPD (02 payload) on nodes 12 to 1C if HDAICOUT.HDA is not present. (I will update this to search and activate only nodes with EAPD capability for universal usage - will test on inverted EAPD AD1981HD codec). -Volume set to 3F on speaker and headphones rather than 7F which was usually too loud on my codecs. (I want to update this to auto-find step values and set volume to 80%). -(currently disabled) show a message at boot for which codec indexes are detected. Interesting responses in file below are $00000400 for power settings F05 indicating a D3cold power setting, this only shows when using verb interface=$0 (Immediate command). According to HDA spec, running the double power reset $0007FF00 brings these out of D3cold state - yet to test. EDIT: Double reset 7FF did not change the D3 cold status response, however once HDAICOUT.HDA is removed audio is quick and efficient. Onward and upward! HDAICIN_ALL_0280_IC.TXT Edited March 5 by isolar Added No HDAICOUT.HDA required for verb interface $0. Also added double reset test result - no change.
deomsh Posted March 5 Posted March 5 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.
isolar Posted March 6 Posted March 6 13 hours ago, deomsh said: 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). I hope he sees this thread and contacts you to advise. His work here is fantastic and there is not much more to do to make it fully universal. Full respect to his amazing work! 13 hours ago, deomsh said: But maybe you can describe and share some code snippets how you dealt with the timing issues? For EAPD enable it is simply: {Enable External Amplifier (EAPD)} hda_codec_write(x,0,AC_VERB_SET_EAPD_BTLENABLE,$02); tgdelay (2); inserted between 'Enable pin output' and 'unmute pin amp' in the HDAenablecircularbuffer function. For verb and codec identify timing fixes: There are many additions to: jhda_reset, HDA_resetCORBRIRB, and HDA_CORBout256 functions. I checked HDA spec for correct initialization timings and found the ResetCorb procedure should be: Clear CORB RUN bit Set CORBRP reset bit (bit 15) Poll until reset bit clears Program CORB base address Set CORB size Enable CORB RUN With this particular BayTrail laptop the wait times are quite picky so slightly longer timings in that listed order of events enabled correct codec detection and HDAICIN to be received without missing any verbs and all on the correct line. For unlimited verbs in HDAICOUT: The ('x') limit has been removed from HDAloadcommands function. If it is permissible to share the amended source code files with you I will be more than happy so you can compare to the original. Let me know if that is a possibility. 13 hours ago, deomsh said: 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. I found on this BayTrail laptop that corb/rirb was not always efficient, however with immediate command (and then adding a check that IC sent verb was confirmed) that it was very fast and nothing was ever missed. I then changed Verinterface to $0 and tried wait1 and wait2 both at $0 with success. Although I haven't tested yet if wait1 and wait2 are actually active when Verbinterface is $0.. do you happen to know? 13 hours ago, deomsh said: 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). This is true when HDAICOUT is renamed/removed. The code attempts to run an auto configure of the codec when this is not present and the 3 volumewidget/sleepingwidget/outputwidget are set correctly. Therefore the EAPD addition to the HDAenablecircularbuffer function I listed above works on all pin widgets for this codec specifically that have EAPD function (and for most Realtek codecs by the look of your list). So by default this also sets EAPD for the headphone widget, however when using Verbinterface $0 I had to unmute the headphone widget to get sound. I also for good measure set connect select to index 1 based on: sent $015F0200; got $00000D0C Connected to NID 0C, 0D (0C is index 0, 0D is index 1) and sent $00DF0200; got $00000B03 Connected to NID 03, 0B - meaning NID$03 is outputting to headphone while NID$02 is outputting to speaker - this can be confirmed in the connection lists in my codec dump and spreadsheet chart I posted a while back. 13 hours ago, deomsh said: BTW is Widget 0x1E your headphone output? Headphone output for this codec is $15. Best identifier for this can be seen in: sent $015F1C00; got $0421401F Jack External, Right, HP Out, 1/8", Green, jack detect, association 1, sequence F. Although in this case the jack is actually black not green.. Speaker output also identified this way: sent $014F1C00; got $90170110 Fixed Internal, N/A, Speaker, Other analog, unknown, no jack detect, association 1, sequence 0 13 hours ago, deomsh said: 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. Correct, this dump has any responses that were $00000000 removed, therefore assume all missing responses are this. The catch? That this runs so fast that the responses received may be before the codec has fully initialized, which leads me to think the F05 responses are D3cold because codec is still initializing. 13 hours ago, deomsh said: 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. As above when I notice verb responses may be before codec has initialized when using the better timing plus Verbinterface $0, I believe after fully initialized the codec powers on the nodes as I identified in earlier tests, so 705 verbs not required for this codec. 13 hours ago, deomsh said: 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. Yes also a viable option. I am unsure if 7F may break or have unknown effects if the codecs max volume does not go this high. But the method I plan to implement will read the steps and 0dB reading for any codec with verb F0012 responses, and set to 80% of 0dB setting, so all codecs should in theory all start at the same volume (80% of 0dB). Not sure if this is correct but I think it could be okay..?
deomsh Posted March 7 Posted March 7 (edited) On 3/6/2026 at 1:00 PM, isolar said: I hope he sees this thread and contacts you to advise. His work here is fantastic and there is not much more to do to make it fully universal. Full respect to his amazing work! 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. On 3/6/2026 at 1:00 PM, isolar said: I found on this BayTrail laptop that corb/rirb was not always efficient, however with immediate command (and then adding a check that IC sent verb was confirmed) that it was very fast and nothing was ever missed. I then changed Verinterface to $0 and tried wait1 and wait2 both at $0 with success. Although I haven't tested yet if wait1 and wait2 are actually active when Verbinterface is $0.. do you happen to know? 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. On 3/6/2026 at 1:00 PM, isolar said: The catch? That this runs so fast that the responses received may be before the codec has fully initialized, which leads me to think the F05 responses are D3cold because codec is still initializing. 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? On 3/6/2026 at 1:00 PM, isolar said: Yes also a viable option. I am unsure if 7F may break or have unknown effects if the codecs max volume does not go this high. But the method I plan to implement will read the steps and 0dB reading for any codec with verb F0012 responses, and set to 80% of 0dB setting, so all codecs should in theory all start at the same volume (80% of 0dB). Not sure if this is correct but I think it could be okay..? 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). Edited March 7 by deomsh P.S
isolar Posted March 8 Posted March 8 9 hours ago, deomsh said: Thanks for the code snippets, I will at least try 'For unlimited verbs in HDAICOUT:' as soon i have more time. Awesome, let me know if you need any help. I work with 2958 get verbs now sending all possible combinations to all widgets from $00 to $32 on the baytrail. In theory this should produce a very nice codec dump to be able to map and see what boot config is like on any codec. I will get out the other testing machines and try it on those too to see if it works. 9 hours ago, deomsh said: How is your HDALOG.TXT? Those responses in your logs look like timing issues. Once the correct initialization and corb/rirb reset timings are implemented this should be corrected. I have: $000F0000=$00000000 $000F0000=$00000000 $000F0004=$00000000 $000F0005=$00000000 First IRS change $10EC0280 First IRS change $00100003 First IRS change $00010001 First IRS change $40000005 First IRS change $17AA3800 First IRS change $000E05F0 First IRS change $00000001 9 hours ago, deomsh said: As you can see I am currently reorganizing my table, plan is to add (max) gain en EAPD. Excellent! F000C verb can be used to find which widgets have EAPD. F0012 verb can be used to identify which step is 0dB on outputs. However, I can't find a way to tell what max volume is, as it is not guaranteed that 0dB is the max volume.. ie some volumes may go +1dB, +2dB etc.. As it is a 7-bit step value then max value possible is 1111111(b) which is 7F(h), but it will be unknown as to what dB that is. Therefore I work from the 0dB step value as the baseline which should be okay for any codec from what I understand. 9 hours ago, deomsh said: At least: did you tested Verbinterface=$0/1 with SleepingWidget disabled in HDACFG.INI, i.e. set to $00 or $FF? Yes for this codec I do not need sleepingwidget enabled, and using Verbinterface $0 and sleepingwidget=$FF is fine - it is possible that because this is an SoC system, maybe the widgets are powered by the system at boot? I have coded specifically for Verbinterface $0 (IC), Verbinterface $1 (corb/rirb) is not initializing the codec for now. I am unsure if this affects anything after boot as I believe this is all only to initialize the codec at boot. I am going to test on a very large wav file (some 700MB+) to see how it plays on Media Player and Winamp. I have currently only tested on boot up, dxdiag, Mplayer, Mplayer2 for smaller files and everything is great. Volume slider Waveout.exe is working great too. The values in Waveout are not the same as the codec step value obviously so maybe I can implement something that can interpret between them. I find using Verbinterface $0 and setting volume (hard coded currently) to 3F in HDA2.DLL changes the [Volume] setting in HDAcfg.ini at boot always back to 0000003F (left channel only) , even though it was set to say 8C008C00 at shutdown. I will check the code and probably find I have implemented the 3F sent not just to the widget, but also to the HDAcfg.ini settings that it writes at boot. I need to separate these.
isolar Posted March 8 Posted March 8 Okay I just tested the updated driver on an IDT-92HD75B3X5 codec 8086_3B56 / 111D_7603. -HP 6550b laptop. With HDAICOUT.HDA, that sends all possible get verbs to all possible widgets from $00 to $32, with sleepingwidget set to $01, volumewidget & outputwidget set to $10: Verbinterface, wait1 and 2 all set to $0, timing working fine and full codec dump obtained in HDAICIN. This codec in particular is quite easy for the audio out path: AFG NID$01, DAC0 NID$10 to PORTD NID$0D. Without HDAICOUT.HDA, with sleepingwidget, volumewidget, outputwidget all set to $10, Verbinterface, wait1 and 2 all set to $0: The only verb that needed to be sent (via QueryHDA.EXE) was $00D70100 to connect PORTD to DAC0 because at boot by default it is set to connect to index 2 which is NID$17 Mixer. Alternatively as PORTD is already set to connect to the mixer, simply unmuting the mixer with $0173701F verb achieves the same result - but with louder volume - see below. Verb $017F000D (mixer input amp caps) returns value $80051F17 - so step value (5) is 1.5dB, number of steps is 1F (indicating max volume-in is step 1F), and 0dB is step 17. This codec is a good example of volume 3F being too low as sound is barely heard with that setting. The F0012 response on AFG indicates 7F is 0dB, so 7F should be set on DAC0 for 0dB volume when routing directly from DAC0 to PORTD. Confirmed this by sending 7F volume to DAC0. Therefore I believe 0dB volume is the same loudness on any codec and should be a comfortable level. On the other hand the mixer $17 has range of -34.5dB to +12dB, so the 7F setting on DAC when routing PORTD through the mixer, and mixer set to maximum step 1F = +12dB (very loud!). Therefore the 7F volume at 0dB is fine routing direct from DAC to output widget, but if routed through a mixer with mixer set to max step the volume will actually be 0dB from DAC PLUS 12dB (specific for this mixer) = +12dB. Mixer set to 0dB (step 17) means no volume change when DAC is also set to 0dB. In summary (I think..) total volume out = dB set on DAC PLUS dB set on mixer if routing through a mixer. --I will add 2 things to the driver: 1) Check 0dB volume and set DAC to it, rather than hardcode to 3F as I have it currently. 2) Check connect select (F01) and ensure speaker out is connected to DAC or audio mixer connected to DAC. Watler's code without HDAICOUT already unmutes the path as long as sleepingwidget, volumewidget and outputwidget are set correct in HDAcfg.
isolar Posted March 8 Posted March 8 Tested on Realtek ALC272 8086_27D8 10EC_0272. Lenovo Ideapad S10-3 Works with Verbinterface, wait1, wait2 set to $0. Sleepingwidget $FF (not required), volumewidget & outputwidget both $02. No HDAICOUT.HDA.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now