Deron416 Posted March 7 Posted March 7 With the Alpha-018 version, the sound is good and clean, no errors. The only problem is that the Windows general volume control is not working. Tested on: WindowsMe, AUDIO: Realtek ALC662 HDA, CHIPSET: North Bridge: AMD 770 and South Bridge: AMD SB710. Many thanks to Drew and everyone who helps in the development of this driver.
deomsh Posted March 7 Posted March 7 (edited) Alpha-018 msfn version just tested on Asrock N68C-S UCC with HDA Controller 10DE:03F0 and codec 1106:4397 (i.e. VT1705) with Windows 98SE. At first I got loud scratchy noise, Master Volume slider is not working. But the Volume Slider in Mplayer2 is working. If the slider is set to absolute minimum (just not muted), I could hear music from my HELLER.MP3 which corresponds to the music actually recorded in this file. Only much lower 'transposed' and very, very slow. I clocked one minute of music with my stopwatch, this took about 3m40s. Edited March 7 by deomsh
schwups Posted March 7 Posted March 7 (edited) 12 hours ago, Drew Hoffman said: I'm glad that it's working for you but I wonder why only that jack works. (There was a bug with the previous version misidentifying all outputs as SPDIF but that should have been fixed.) Are you able to install the Debug version (HDA.sys in the obchk/i386 folder), disable the device, restart, open Sysinternals DebugView, enable the device, and save the log file? I used HDA-debug.sys (renamed to HDA.sys) from alpha 18 with your instructions from github. I6U9A7.7z Edited March 7 by schwups
Guest Drew Hoffman Posted March 7 Posted March 7 13 hours ago, deomsh said: Alpha-018 msfn version just tested on Asrock N68C-S UCC with HDA Controller 10DE:03F0 and codec 1106:4397 (i.e. VT1705) with Windows 98SE. At first I got loud scratchy noise, Master Volume slider is not working. But the Volume Slider in Mplayer2 is working. If the slider is set to absolute minimum (just not muted), I could hear music from my HELLER.MP3 which corresponds to the music actually recorded in this file. Only much lower 'transposed' and very, very slow. I clocked one minute of music with my stopwatch, this took about 3m40s. It seems the VIA VT1702S and VT1705 are rejecting the sound data format 0x11 for 16-bit stereo 48khz (or at least the response to verb 0xA on the VT1702S is 0xC0000001 which is not expected and not documented in the datasheet). So it is set for a very incorrect bit depth and sample rate and possibly mono instead of stereo (I get static only from the Left channel on the VT1702S). 9 hours ago, schwups said: I used HDA-debug.sys (renamed to HDA.sys) from alpha 18 with your instructions from github. I6U9A7.7z 2.79 kB · 4 downloads Then on the VT1708 apparently the only working output path is the first one that is set up (because it is the first one enumerated from the AFG) even though the log also states 4 output paths are successfully programmed. I don't know if this one is setting the correct sample rate as the log cuts off before a sound is played but from your description it is playing properly.
isolar Posted March 7 Posted March 7 (edited) 1 hour ago, Drew Hoffman said: (or at least the response to verb 0xA on the VT1702S is 0xC0000001 which is not expected and not documented in the datasheet) 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? Edited March 8 by isolar
schwups Posted March 9 Posted March 9 On 3/8/2026 at 12:38 AM, Drew Hoffman said: Then on the VT1708 apparently the only working output path is the first one that is set up (because it is the first one enumerated from the AFG) even though the log also states 4 output paths are successfully programmed. I don't know if this one is setting the correct sample rate as the log cuts off before a sound is played but from your description it is playing properly. Ok I've done this once more and afterwards I started to play a song with VLC. DebugView additionally logged: 00000306 130.59310240 HDACommon: [CAdapterCommon::ProgramSampleRate] 00000307 130.59310800 HDA_Codec: [HDA_Codec::ProgramSampleRate] 00000308 130.59311360 HDA_Codec: AFG node reports no sample rates supported 00000309 130.59311920 HDA_Codec: Sound data format 0x11 00000310 130.59344160 HDACommon: Samplerate changed to 48000. 00000311 130.59697440 HDACommon: [CAdapterCommon::ProgramSampleRate] 00000312 130.59698000 HDA_Codec: [HDA_Codec::ProgramSampleRate] 00000313 130.59698560 HDA_Codec: AFG node reports no sample rates supported 00000314 130.59699120 HDA_Codec: Sound data format 0x4011 00000315 130.59731200 HDACommon: Samplerate changed to 44100. And yes, it seems to play properly from the black jack.
deomsh Posted March 10 Posted March 10 On 3/8/2026 at 12:38 AM, Drew Hoffman said: It seems the VIA VT1702S and VT1705 are rejecting the sound data format 0x11 for 16-bit stereo 48khz (or at least the response to verb 0xA on the VT1702S is 0xC0000001 which is not expected and not documented in the datasheet). So it is set for a very incorrect bit depth and sample rate and possibly mono instead of stereo (I get static only from the Left channel on the VT1702S) I have the impression my output is mono too (same with Watler's driver, where sound is 'good' as such), but I thought my 'extra' headphone cable was the culprit. I will try to test.
deomsh Posted March 11 Posted March 11 (edited) I'd run some tests. The good news is with an old headphone with only two isolating bands in the jack, everything was normal with Watler's driver on VT1705. Balance button of Mplayer2 worked as expected. The bad news is: if I only installed your driver (MSFN version 018) indeed only Left Channel produced sound. I tried to send Verbs with INTELHDA.EXE (from Watler's AHDAO) using CORB, but this gave a blue screen and unresponsive computer. Then I tried INTELHDA.EXE together with HDA2.DLL and not much was needed to get good sound. From my notes: ======================================================================================== PLAYBACKPATH: 1C [PW3] - 16 [MW0] - 10 [AW0] ACTIVATED AFTER FULL RESET - MPLAYER2 IS PLAYING FIRST: $01070610 => HEAVY NOISE LIKE SOUND, WITH VOLUME SLIDER LOW SOME MUSIC HEAVILY DISTORTED THEN: $01024011 => NORMAL MUSIC - BOTH CHANNELS OR: $01020011 => NORMAL MUSIC - BOTH CHANNELS (NEEDS RESTARTING MUSIC) WITH CHECK: $010A0000 => 00=$0000000000000011 EAPD NOT NEEDED: $01CF0C00 => 00=$0000000000000000 IF SET NO DIFFERENCE NOTHING MORE NEEDED IN CASE OF HEADPHONE AT REAR GREEN JACK ========================================================================================= You can read the whole story in the attachment if you like. N68CSUCC.INTELHDA.ZIP P.S. I am nut fully sure about the Mixer 16h, I expected somehow the inputs must be opened because after codec reset: GAIN INPUT AMP: $016B0000 => 00=$0000000000000097 $016B2000 => 00=$0000000000000097 But if, it will make probably no difference in case of your driver. And now I am tired of testing with the CORB. Edited March 11 by deomsh Typo
deomsh Posted March 13 Posted March 13 (edited) I did more tests with HDA2.DLL and INTELHDA.EXE (AHDAO) on N68C-S UCC with VT1705. First with CORB from cold boot. This time more had to be done with Pin Widget 1Ch and DAC 10h. All in all it was as expected, only default timing (25) was a bit to low (first response zero's). Some highlights: OUTPUT WIDGET POWER $010F0500 => 00=$0000000000000033 $01070500 => NO SOUND $010F0500 => 00=$0000000000000000 OUTPUT WIDGET GAIN $010B8000 => 00=$0000000000000000 $010BA000 => 00=$0000000000000000 $0103B02A => NO SOUND OR CRACKLES $010B8000 => 00=$000000000000002A $010BA000 => 00=$000000000000002A Second I changed to Verbinterface=$0 and did a fully cold boot, Because I forgot to set al Widgets in HDACFG.INI to $FF, I made the changes and did a full reboot. Afterwards I started with the Immediate Command interface from INTELHDA.EXE. Most things where fully as expected, but not all. I copied all response messages. I have no idea what to do with the extra information besides the Verb response, but you will (I assume): OUTPUT WIDGET POWER $010F0500 CODEC 0 forgot Order 23 times! Codec 0 Was Busy 851 times! Codec 0 Sent Data ($00000000) Probably the earlier Power state survived the reboot (through the BIOS)? Enabling music while Mplayer2 was playing, was more or less as expected. But I couldn't get the 'good' response to the Stream format Verb after using the appropiate SET Verb: OUTPUT STREAM: $010F0600 CODEC 0 forgot Order 46 times! Codec 0 Was Busy 1674 times! Codec 0 Sent Data ($00000000) $01070610 => REASONABLE SOUND, LEFT ONLY $010F0600 => SOUND STOPPED CODEC 0 forgot Order 96 times! Codec 0 Was Busy 3467 times! Command 0 Valid but CODEC still busy! Codec 0 Sent Data ($00000000) AFTER EXIT MPLAYER2: INTELHDA NOT CLEAR YET AFTER CLEAR IC NEEDED AGAIN TO GET RESPONSE: $01070610 $010F0600 CODEC 0 forgot Order 256 times! Codec 0 Was Busy 9274 times! Codec 0 Sent Data ($00000010) OUTPUT FORMAT: CODEC 0 forgot Order 95 times! Codec 0 Was Busy 3444 times! Codec 0 Sent Data ($00000031) $01024011 CODEC 0 forgot Order 107 times! Codec 0 Was Busy 3903 times! Codec 0 Sent Data ($00000000) $010A0000 CODEC 0 forgot Order 57 times! Codec 0 Was Busy 2065 times! Codec 0 Sent Data ($00000000) RESTARTED MPLAYER2: NORMAL STEREO MUSIC But with CORB I had no problems to read out Stream format just set. After using CORB 'good' response with Immediate Command too. So maybe you can make some version with CORB? I am willing to test. Full description of all tests in the two attached files. VT1705_CORB_VERB.txtVT1705_IC_VERB.txt Edited March 13 by deomsh Typo's
awkduck Posted March 22 Posted March 22 (edited) On 3/2/2026 at 4:06 PM, Drew Hoffman said: 3dmark01 with SoftGPU achieved 1 frame per benchmark section and too slow to return a score. Not the primary cause, but adding salt to the injury, this is an "in-order-execution" CPU. If not reaching maximum CPU load, you'd think that audio stutter could be ironed out. But I can see there being real issues, with SoftGPU. With a similar spec CPU, and out-of-order-execution, I'd expect "maybe" 3fps (possibly a little higher using TitaniumGL). Anytime FPU is really needed, this CPU is probably in trouble. Edit:The Via Nano is out-of-order, and then some Edited March 22 by awkduck
Guest Drew Hoffman Posted March 22 Posted March 22 Fixed the crash on Intel mobile chipsets. it was failing on the Intel Display Audio codec and then double-freeing a pointer. No guarantees that this will produce sound for you though. https://github.com/andrew-hoffman/WDMHDA/releases/tag/Alpha-018-1
SweetLow Posted March 23 Posted March 23 9 hours ago, Drew Hoffman said: Fixed the crash on Intel mobile chipsets No BSOD, no hardware problem after reboot, but the same short loops on Core gen10 system.
isolar Posted March 23 Posted March 23 (edited) 12 hours ago, Drew Hoffman said: Fixed the crash on Intel mobile chipsets. it was failing on the Intel Display Audio codec and then double-freeing a pointer. No guarantees that this will produce sound for you though. 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? Edited March 23 by isolar added update:
deomsh Posted March 23 Posted March 23 Alpha-018.1 just tested on Asrock N68C-S UCC with HDA Controller 10DE:03F0 and codec 1106:4397 (i.e. VT1705) & Windows 98SE. Same problems as reported earlier.
Guest Drew Hoffman Posted March 23 Posted March 23 4 hours ago, isolar said: 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? There isn't any filesystem access at the time the driver first loads but I could keep all the debug messages in a circular buffer and save them out later, or delay the codec init until something actually tries to play a sound. You can see debug messages with Sysinternals DebugView if you boot with the HD Audio Controller device disabled, then launch DebugView, then enable the device. Otherwise a kernel debugger and hardware serial port is required. You should also try the debug version of the driver in the objchk\i386 folder, someone else reported that the debug version was working while the release version wasn't for a Realtek ALC292 so maybe some additional delays are required. I don't claim to be an expert in this stuff anyway, I only built this driver because no one else was working on it.
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