isolar

Confirmed I always set power on first, then stream format later after path is connected. This works on ALC272 with latest HDA2.DLL. Works with Verbinterface=$1 and $0 - very fast with $0 (IC mode)! Actually the speaker on these devices is interesting as it shows the connection type from F1C get verb as a 'ATAPI Internal' - 3h rather than an 'Other Analog' - 7h as most laptops do. I wonder if this has something to do with it? However the log shows it definitely is identified as a speaker so maybe not the problem, and back to the power node i'm thinking that the WDM driver routes through the mixer node 0E (?) so possible your original thinking of powering on this node ($14) might do the trick.

I think you are correct here as when $70C02 is not sent to the NC8430 laptop, the mute light on the mute button is on, but it is off when your driver initializes which indicates it has worked and the speaker is unmuted and active. BTL not necessary here. I guess it wouldn't hurt to send 'power on 70500' to the power node to try? This is the only test machine I have with that type of widget and when looking into it I found it seems to just be able to set to D0 or D3 and in turn adjust all connected nodes from the Connection List Entries to on or off. This affects the main mixer node $0E and it has 9 connections to it. DAC $03 can route through this mixer and then to node $05 so may just be the cause of it bypassing the speaker for headphones?

No probs! Attached below dbgview logs for those 3. Looks like it does find the speaker on the AD1981HD machines but rolls over to headphones as the output. The AD1981HD codec has a power node $14 which handles the sum mixer and connects to all pins. Using Watler's driver and setting EAPD to $02 on node $05 works to power the speaker. There is talk on the linux threads about an inverted EAPD on this codec but I could never figure out how it is inverted and works for me like normal. To my knowledge none of these machines use GPIO for audio out or jack detect. Probably unsolicited response required to switch between LineOut and Headphones on the ALC887. AD1981HD_6710B_DBG_INSTALL.LOG AD1981HD_NC8430_DBG_REBOOT.LOG ALC887_AMD-K30BF_DBG_REBOOT.LOG

Well done this is coming along great! Tested on 7 machines: Lenovo S20-30 Laptop, Realtek ALC280 - 8086_0F04 / 10EC_0280 - headphones/speaker interchange working - reboot required for volume control Lenovo S10-3 Laptop, Realtel ALC272 - 8086_27D8 / 10EC_0272 - headphones/speaker interchange working - no reboot required for volume control Lenovo E530 Laptop, Conexant CX20671 - 8086_1E20 / 14F1_506E - headphones/speaker interchange working - no reboot required for volume control HP 6550b Laptop, IDT 92HD75B3X5 - 8086_3B56 / 111D_7603 - headphones/speaker interchange working - no reboot required for volume control - needed to nudge volume control to get sound HP 6710b Laptop, Soundmax AD1981HD - 8086_ 284B / 11D4_1981 - headphones working only, speaker not working, audio stream stuttering - no reboot required for volume control (needs to route to NID$05 for speaker) HP NC8430 Laptop, Soundmax AD1981HD - 8086_27D8 / 11D4_1981 - headphones working only, speaker not working - no reboot required for volume control (needs to route to NID$05 for speaker) AMD K30BF_M32BF Desktop, Realtek ALC887 - 1022_780D / 10EC_0887 - front headphones & rear lineout working - headphone/lineout interchange not working - no reboot required for volume control

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