isolar

Okay I managed to recompile with an added verb checker and ran a verb test for power, stream and channel settings, EAPD, Pin output, volume and all looks good, please see attached log. Everything else in the log seems to look good so I am stumped here.. WDMHDA19_VERBS.LOG

Ah that makes sense with the inf file, I didn't try the "Let Windows pick best driver" approach yet but will try now. Recently I worked with @deomsh to update his inf for Watler's driver and there is a decent list of controller IDs and names in there at the moment. So far this has identified all controllers on the 6 laptops i'm currently testing with. It may come in handy? Excellent I am keen to see where the audio is being blocked from with your driver on this codec so will try to add some debug read verbs to codec.cpp and see if I can get it working. I believe visual c++ 6.0 required to compile? If you have any advice on this please let me know your thoughts and I will get it underway. If I find anything I will let you know, if not at least can rule out the verbs as the issue. Onward and upward!

Interesting, I have been looking into how this works but still learning. I believe the exact same stream format must also be set in ISD0FMT—Offset 92h of memory mapped PCI register or strange results happen. I will look into this. Sure thing, attached below. For now it is simply your original Genhda.inf combined with the device id's you posted last, with just the 1 addition of a registry key removal to ensure latest driver date is shown in multimedia settings. GENHDA16.INF

Tested on 8086_0280 but sadly no sound. When attempting to install this version there were no devices that appeared in the device selection part, the window that pops up is blank and I cannot proceed with install as there is no device to select (something in the inf file not working on this controller now). This is where I usually see the WDM driver and can select it. I used the inf file from v18-1 and it appeared and then I picked the debug version of HDA.SYS v19. All installed and according to the log the codec is initialized along with the HDMI codec now, so all looking good in the debugview log (attached below). In multimedia settings I can see the audio driver and mixer is enabled, however the devices tab is all greyed out. Not sure if it is the verb sequence or something else but for reference on this codec I used this order for initialization: Set Power - AFG Set Power - DAC Set Power - Mixer Set Power - Pin Enable Output - Pin Enable EAPD - Pin Set Stream Format - DAC Set Channel/Stream ID - DAC Unmute Output Amp - DAC Unmute Output Amp - Pin Is it possible to add some send verbs to the codec.cpp file and have the response output to the debugview log, so in theory a list of response verbs that show that everything is initialized as it should be? For example: sendverb $002A0000 and receive response $00000011 to show that 48khz is set? WDMHDA19.LOG

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!

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

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

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

Thank you! I will have a go at the MSVCR dll replacement and try v3.x. So far v1.11 working, but audio stream has some bad stutter - testing on a 700mb wav file(!!). Not sure at all.. but I think something might be funky with the nosnoop setting on reboot possibly..? However WPCREDIT shows all is well so i'm not sure I am correct with this assumption. Where can I find the documentation on the nosnoop setting - PCI registers? (EDIT: Found them https://www.yumpu.com/en/document/read/50745087/intelar-system-controller-hub-intelar-sch-datasheet/119). I found with further testing on the baytrail that when I do a fresh install of the driver the sound is clean, but on next reboot the sound has a high frequency over the top of it for the windows startup sound and on smaller sound files - warm or cold boot = no difference. Double codec reset is being run at every boot.. might be something to do with it? This only happens on the Baytrail laptop where nosnoop needs to be set. Further testing required on the other laptops but seem to have clean audio on reboot on those which is why I am investigating nosnoop. This is with the auto patch pcipatchb=$7900 I implemented set by reading the PCI DID 0F04. If I completely uninstall the driver and reinstall then again on the 1st boot the sound is clean again. Scratching my head.. maybe nosnoop is not the issue and it is something to do with the stream settings or CORB/RIRB? DMA? I am very fresh on these so am doing a lot of reading of the Intel HDA Spec and PCI registers. Any advice or experience here greatly appreciated! EDIT2: The wav file plays on the other laptops but it is slow.. maybe 10-20% slower than it should be. It is a 16bit 44.1khz wav file. Any suggestions on what is happening will be appreciated!

Thank you but really not possible without your collaboration! Collaborate, fill the gaps, benefit for the community. I hope one day it will all be of use. Watler is hopefully proud that his work carries on today. Using F000C verb you can determine output capable pins and headphone capable. Then with F1C verb, you are able to determine, fixed internal/speaker and jack external/headphones outputs. Once established you can find the shortest path backwards to the DAC using F02 through the connection lists until output path is established. As I am only testing on laptops, I need to run tests on PC with non-fixed speakers to see if still operational in that condition. I have a feeling external jack in that situation and possibly identified as Line Out? Hmmm that is interesting, I seem to recall in earlier development that volume was indeed set to $57 and I couldn't figure out why.. seems you are correct and running codec reset sets 0dB automatically! I will look further into this thank you! Certainly! Attached below. I had a quick look at your chart and can see you will indeed be able to update some of the cells. Apologies for the crudeness I have not had time to clean it up yet. Excellent glad this will be of use! For my current beta testing it simply logs in HDALOG file when there is a change and indicates either headphones or speaker active. Still new so some tweaking to do but promising so far and zero annoying pop ups.. unless you would like one? Excellent thank you for this list I will have a go at all of them! Your updated INF file will come in handy. Stability so far no issues but I am yet to 'pressure test' everything. VLC player is next on my list.. from memory I need kernelex for the latest possible version 2.x? Any tips here appreciated. The force codec index is relatively easy as I will just convert my initial codec index selector that popped up at boot into the hdacfg file. Although with the timing fixes I implemented I currently do not have an issue with correct codec index. A volume slider is definitely high on my list! Vendor specific widgets, if you are able to provide any info on those then i'm happy to look into it. I believe they are filters attached to different widgets but have never looked into them. Full compliance to HDA spec eventually will be awesome! Currently much work to be done HDAICIN_ALL_IDT92HD75B3X5.TXT

Okay more testing. Firstly apologies, a lot of the information below is based on my assumptions and not necessarily educated diagnosis! My earlier initial test was done by booting with driver active, disabling in device manager, opening debugview, then enabling the driver - without restarting. STATESTS confused me. But.. This time I did what you said, disable driver in device manager, reboot, open debugview, enable driver. This time STATESTS = 0005! And all widgets found and identified for codec 0! Also, output path correctly found for speaker AND headphones! So, the timing is fine when enabling the driver after boot. Therefore I recommend adding 521 microseconds delay at boot for codec initialization as per HDA spec (below). Apologies if this is already implemented I am not familiar with your code. The next issue seems to be according to debugview, it attempts to enable the HDMI codec (codec 2) which then takes over the CORB/RIRB that was setup.. (?? I am purely speculating here and I am not sure I am reading this correctly?) The codec 2 initialization fails of course, however debugview reports 'Initialized 1 codecs', therefore shows success of codec 0 still. It then possibly halts logging at QueryDeviceCapabilities.. possibly trying to find outputcaps for codec 2? However once codec 0 was initialized it is okay to stop unless the intention is to also try to activate the HDMI audio port? Please see the attached log file, hopefully this will help! To note: I cannot see any verbs sent or received.. is it possible to see? Is it possible to change the widget node readouts to hex values rather than integers for ease of debugging? WDMHDA18.LOG

Debugview all good, thankyou! I tried the debug version but no sound... yet... Investigation into debugview shows STATESTS reported as B76C. When experimenting with Watler's driver STATESTS always showed as 0005 on this codec - indicating codec index 0 and 2 found - 0 being the correct out, 2 being the HDMI audio out. Resetcontroller reports as failed as it cannot latch onto codec index 0, the same problem I had when first trying this codec. I had to fix it with delays and timing as you suggest above. I think it was wait 521 microseconds after reset, then begin initialization. From my notes: 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. I think i tried 50ms as a base between each step then minimized those. Hope this info can help!

Okay no more BSOD on 8086_0F04/10EC_0280. Boots up all good! - no sound as of yet... Driver reports active in Multimedia settings/Devices for all 3 - Audio devices, midi devices and instruments, mixer devices. However on the audio tab no playback devices are shown (all greyed out). NoSnoop confirmed it has reverted to $00 (PCIPatch $7900) so all good there. Something likely missing in the verbs.. Audio out path for this codec is: $02 DAC, DAC Amp Out Caps 0dB is $57. $0C Audio Mixer, should only require unmute input. Index 0 connects to $02 DAC. $14 Output Pin. Output pin $14 requires EAPD $02. Index 0 connects to $0C mixer. Hopefully this info helps! Update: Likely codec did not initialize properly as when verbs/playback output path is an issue and codec has still initialized, then it is possible to still play sounds in the sound tab or in mplayer2, however play button in all is greyed out.. any way to implement a basic text log file to this that I can use to provide feedback on?

Some more success! Widget parser is now working correctly to establish correct line out pin, mixer pin and DAC to obtain playback path. Analog only, digital is skipped. Automatically checks and sets the connections. Automatically sets stream and channel settings. Automatically sets volume based on 0dB step level. Automatically enables EAPD if required. Automatically applies PCI patch if required (on 0280 codec). Tested and working on Realtek 0280 codec, Realtek ALC272 codec, and IDT 92HD75B3X5 codec - All installed from scratch and produce sound automatically, no config required. IDT codec note that may be of use to @Drew Hoffman - I found this particular IDT codec provides the output amp caps from the AFG node rather than the DAC node which Realtek does. I read DAC first and if output amp caps are zero I fall back to reading the AFG and applying 0dB to the DAC. Unsure what other codecs do it this way. Next step I will integrate auto headphones with jack detect, then look into microphones. Any other suggestions?

Yes, seeing if possible. So far sound produced successfully with my new unit 'HDACODEC.PAS' on the 10EC_0280 codec without sleepingwidget, volumewidget or outputwidget present in HDAcfg.ini. No manual configuration required! I have also located the section of code responsible for PCIPatchB and have started to add the DID's from your list. So far it looks promising, but still more work to do. Interesting, I have located a section of code that is handling real mode and protected mode with some 255 limits so quite possibly something there. When I get some time I might look into win3.1 also. Yes the delay was long for me at first also, but since fixing the timing it is much quicker now. Great that sound is working, especially on a Ramdrive! Awesome work! Excellent! Hopefully this helps to map any future codecs. A new record! I had a look at your files, I randomly picked HDAICIN.BD4 and notice something strange on the F0005 response.. : Node $01 replies as an Audio Function Group - This is normal Nodes $19-$1E & $22-$23 also reply as Audio Function Group with unsolicited caps? - very strange. Total of 8 nodes reporting this. $000F0004 (root) responds that there is only 1 connected AFG node which is node $01 (AFG) - correct. Then $001F0004 responds that the highest node number is 24 (18h) with the first node being 16 (10h). So 9 widget nodes connected to the AFG. 8 of these report they are AFG with unsolicited caps?

Understood, I hope the other project gets good momentum for you. My excitement for this driver has surpassed my ability to keep up also! Lots of ideas running through my head so I try to brain dump here before I forget. Exactly, removing the x limit should in theory run unlimited verbs. The only other check I implemented was: The line it reads must start with a '$' and it will bypass any ';;' or start/begin. Unsure if that is necessary but just for completion. Hmm with your Win3.1 vs Win98 test, it seems something in Windows 3.1 limits it to 255 verbs even with x unlocked.. but I have not tested Win 3.1, only 98 so cannot advise yet. I will be keen to find out why that is. I am now working on a new unit to incorporate with this driver that initializes HDA codecs just like the Linux method. Currently it is a new .PAS file that can be called from DRVPRC.PAS to initialize any codec (in theory), power on any necessary widgets, identify output paths and set connections correctly, enable DAC max volume, enable EAPD where necessary.... and eventually allow headphones with jack detect. Watler has already done the heavy lifting, just the Linux widget initialization method is to be put into PAS format and compiled. I will send updates on this when I have some results to show. Attached is the HDAICOUT for all verbs for all widgets from $00 to $32 if you want to try. Only missing F0204 verb for any connection list entry greater than 0-3. F0204 will show connection list entry 4-7 if they exist but I haven't found a need for it yet. HDAICOUT.HDA

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.

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.

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

According to HDA spec that response indicates Non-PCM, 44.1kHz, 8-bits, 2channel. I have not dealt with non-PCM before.. not sure but would that indicate maybe AC97?

Alpha 018 - Fatal exception 0E at 0028:C001545A on Bay Trail N2840 system here. 8086_0F04 / 10EC_0280

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! 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. 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? 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. 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 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. 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. 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..?

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

Fatal exception OE at 0028:C001545A on Bay Trail N2840 system confirmed here.

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