isolar Posted March 23 Posted March 23 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!
isolar Posted March 24 Posted March 24 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
schwups Posted March 24 Posted March 24 Asus P5LD2SE, i945P, ICH7 - 27D8 Codec Analog Devices ADI1986A: Only right speaker very faint/weak and can be choppy. DebugView log: 00000000 0.00000000 00000001 0.00000400 HDA Controller: VID:0x8086 PID:0x27D8 : 00000002 0.00001040 Intel ICH6/7 00000003 0.00017040 00000004 0.00017440 Init HDA Controller! 00000005 0.00176960 00000006 0.00177360 Codec #0 VID:0x11D4 PID:0x1986 00000007 0.00309680 00000008 0.00310000 00000009 0.00310400 LIST OF ALL NODES IN AFG: 00000010 0.00313680 00000011 0.00314080 2 00000012 0.00342160 Output Converter 1 6 00000013 0.00342560 3 00000014 0.00354720 Output Converter 00000015 0.00355040 4 00000016 0.00368560 Output Converter 00000017 0.00368880 5 00000018 0.00382400 Output Converter 00000019 0.00382800 6 00000020 0.00399280 Input Converter 18 00000021 0.00399680 7 00000022 0.00473200 Audio Mixer 3 9 19 20 21 22 23 24 00000023 0.00473520 8 00000024 0.00488560 Audio Mixer 7 00000025 0.00488880 9 00000026 0.00512720 Audio Mixer 4 5 00000027 0.00513040 10 00000028 0.00545520 Audio Selector 7 4 5 00000029 0.00545920 11 00000030 0.00571040 Audio Selector 7 4 00000031 0.00571440 12 00000032 0.00596640 Audio Selector 4 7 00000033 0.00596960 13 00000034 0.00620800 Audio Selector 5 8 00000035 0.00621120 14 00000036 0.00646320 Audio Selector 8 17 00000037 0.00646640 15 00000038 0.00718560 Audio Selector 31 32 29 29 39 40 41 42 00000039 0.00718880 16 00000040 0.00751360 Audio Selector 32 28 31 00000041 0.00751760 17 00000042 0.00775600 Audio Selector 15 43 00000043 0.00775920 18 00000044 0.00804000 Audio Selector 17 34 00000045 0.00804400 19 00000046 0.00820880 Audio Selector 17 00000047 0.00821200 20 00000048 0.00837760 Audio Selector 35 00000049 0.00838080 21 00000050 0.00854560 Audio Selector 34 00000051 0.00854960 22 00000052 0.00871440 Audio Selector 33 00000053 0.00871760 23 00000054 0.00889680 Audio Selector 16 00000055 0.00890000 24 00000056 0.00914240 Audio Selector 25 36 00000057 0.00914640 25 00000058 0.00922400 Beep Generator 00000059 0.00922800 26 00000060 0.00942560 Pin Complex Port Grn Headphone Out 10 00000061 0.00942880 27 00000062 0.01122320 Pin Complex Port Grn Line Out 11 00000063 0.01122640 28 00000064 0.01270400 Pin Complex Port Blu Line Out 12 00000065 0.01270720 29 00000066 0.01419520 Pin Complex Port Pnk Line Out 13 00000067 0.01419840 30 00000068 0.01427680 Pin Complex No Connect 00000069 0.01428080 31 00000070 0.01440480 Pin Complex Port Pnk Mic In 00000071 0.01440800 32 00000072 0.01453200 Pin Complex Port Blu Line In 00000073 0.01453520 33 00000074 0.01461440 Pin Complex No Connect 00000075 0.01461760 34 00000076 0.01474320 Pin Complex Internal Blk CD not considered 00000077 0.01474640 35 00000078 0.01483920 Pin Complex No Connect 00000079 0.01484240 36 00000080 0.01493440 Pin Complex No Connect 00000081 0.01493760 37 00000082 0.01513520 Pin Complex Port SPDIF Out used 2 00000083 0.01513840 38 00000084 0.01585600 Power Widget 7 8 19 20 21 22 23 24 00000085 0.01586000 39 00000086 0.01611120 Audio Mixer 31 29 00000087 0.01611520 40 00000088 0.01636640 Audio Mixer 31 32 00000089 0.01637040 41 00000090 0.01660800 Audio Mixer 29 32 00000091 0.01661120 42 00000092 0.01694960 Audio Mixer 31 29 32 00000093 0.01695360 43 00000094 0.01711840 Audio Mixer 15 00000095 0.01712240 Init these output PINs: 00000096 0.01712640 00000097 0.01713040 SPDIF output 00000098 0.01801280 00000099 0.01801680 Headphone output selected 00000100 0.01960800 00000101 0.01961200 4 Output paths found 00000102 0.01961680 00000103 0.01962080 ResetController Succeeded! 0x0 00000104 0.01964480 Init Finished Successfully! 00000105 0.02003120 SSE2 1
Guest Drew Hoffman Posted April 19 Posted April 19 Released version Alpha-019 which will init Intel Display Audio, fixes some memory bugs and will install on Windows 2000 and XP. https://github.com/andrew-hoffman/WDMHDA/releases/
isolar Posted April 20 Posted April 20 (edited) 17 hours ago, Drew Hoffman said: Released version Alpha-019 which will init Intel Display Audio, fixes some memory bugs and will install on Windows 2000 and XP. 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 Edited April 20 by isolar Added log file attachment
Guest Drew Hoffman Posted April 20 Posted April 20 (edited) I added ExcludeFromSelect=* to this version of the inf so it only works if you "Let Windows pick the best driver to install" and it doesn't show up in the "Select the driver from a list" workflow. That was copied from the AC97 sample driver inf. e: Changed it back to how it was before and the driver shows up in the Have Disk list. Updated the download file. Yes it is possible to add some read verbs and debug prints to the end of codec.cpp at least in debug mode, and enable more debug logging of all verbs sent and codec responses. I just have a lot of it turned off most of the time as irrelevant. The whole debug logging system could stand to be overhauled anyway, there are actually 3 different versions in use here and the logging selections should be per file and toggleable from the debugger instead of requiring a recompile. Edited April 20 by Drew Hoffman
isolar Posted April 21 Posted April 21 (edited) 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! Edited April 21 by isolar updated some words
isolar Posted April 21 Posted April 21 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
Guest Drew Hoffman Posted May 15 Posted May 15 (edited) Released version Alpha-020 which destroys the Stream Descriptor when playback is stopped and recreates it when started again, which mostly fixes the problem of no or choppy sound when skipping through music tracks. There is still a similar issue with rapidly pausing and unpausing a stream that I haven't found a fix for. I tried to fix any small issues with the inf file and it should install properly on a fresh system though you may have to restart after installation for the system audio components and volume control to be loaded. https://github.com/andrew-hoffman/WDMHDA/releases Edited May 20 by Drew Hoffman
deomsh Posted May 23 Posted May 23 Although latest update WDMHDA Alpha-020 is probably not ment for VIA-codecs, I couldn't resist testing while working on Windows 98 FE installations. Same problems as reported earlier (N86/VT1705). DxDiag: after ignoring the warning there was a problem with Sound I got a non-specific Blue Screen with some problem on 0028:00000009 (non-fatal). Not sure if DxDiag was used earlier this way.
Guest Drew Hoffman Posted May 23 Posted May 23 (edited) Right, I still need to fix whatever is wrong in the initialization verb sequence for VIA and Sigmatel/IDT codecs and add polling for the headphone jack. Haven't had much time to work on this lately and when I have, the real hardware hasn't been available. Maybe you could get somewhere if you were able to get the project building and then take a look in codec.cpp? You can ask me anything about getting the development environment set up. I'd be willing to take patches or even give project commit access for either of these fixes. There were some problems with DXDIAG crashing previously that I have not been able to reproduce and may have been tied to SoftGPU. Next time you get that bluescreen, can you take a photo and see what VxD is responsible for the crash? Edited May 23 by Drew Hoffman
deomsh Posted May 23 Posted May 23 (edited) Here you go, but as said: unspecific (Fatal Exception 0E) I will try to understand codec.cpp (as a non-programmer). But there is some sound on lowest volume level of mplayer2, only heavily distorted and 'transposed' one er more octaves lower - listening with Headphones (all reported earlier). Edited May 23 by deomsh
deomsh Posted Saturday at 12:06 PM Posted Saturday at 12:06 PM (edited) Hello @Drew Hoffman I did long testing of VT1705 on my N68 board with WDMHDA Alpha-020 (returned to Windows 98SE - for other reasons). I studied codec.cpp on your behalf, but I couldn't find anything special. With help of Google AI I managed to use DebugView. To me it seems the problem is on the HDA-controller/ Driver level. See complete documentation in VT1705.zip below. I let my AI-agent analyse the log's from DebugView, seems to corroborate my idea. Today I asked my AI-agent to analyze your source code too. I had the luminous idea to ask for comparision with source code of HDADRVO11 (latest, published version - has absolutely no problems with my system). During the testing phase of this version Watler produced eleven versions. Because he is rather sparse with words (I believe I am not) I used my AI-agent to analyse changes. Everything runs in a (virtual) VSCode directory in Ubuntu, so my AI-agent from ai.pi studies earlier analysis/ log's/ code too). AI's analysis (GLM5 if I remember well) of WDMHDA Alpha-020 seems to make (some) sense to me, but in my language we say: "Een kinderhand is gauw gevuld" (in English probably: "Small things please little minds"). Maybe you can use the result of AI's analysis. VT1705 on N68 with WDMHDA.020 - source code compared with HDADRV9O11 .md VT1705.ZIP Edited Saturday at 01:48 PM by deomsh Corrections
Guest Drew Hoffman Posted yesterday at 08:30 PM Posted yesterday at 08:30 PM (edited) I fixed some bugs with the CORB and RIRB setup (what the AI said wasn't quite correct but there were some bugs nonetheless) and increased the timeout for the CORB reset which should help on the controller side. I have an Acer SFF with NForce 705 chipset somewhere which I will test on to make sure that is all working properly. For the VIA audio codec, I already know that there's a problem with the codec not accepting the sound data formats and returning 0xC0000001 when trying to read the format back which I think is an error value though it isn't described in the datasheet. Maybe the format needs to be set on a different node or maybe the order of setup verbs is wrong. I also have a thin client with a VT1702s codec somewhere that I can test this portion on. e: Oh right, 0xC0000001 is STATUS_UNSUCCESSFUL and that means isn't coming from the codec, it's the return value from hda_send_verb when the codec doesn't send a response, and it won't be sending a response because the PIO communication is broken after the codec is initialized (because it keeps trying to probe for other codecs on the bus). That's indicating a different problem than I thought it was indicating. Edited 21 hours ago by Drew Hoffman
deomsh Posted yesterday at 09:14 PM Posted yesterday at 09:14 PM As said, I am not a programmer - sorry my AI-agent has been wasting your time. He also said he could rewrite your code, I had 'only' to do the compilation myself. With my earlier experiences with AI modifying existing bootcode fresh in mind, I thought I would make you no competition But my N68/VT1705 is always ready for testing.
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