[HDA] very quiet on Lenovo laptop (due to hda mixer?)

[ttcoder]

Audio is very quiet on this R61 laptop, even if cranking up media_server mixer volume at +18 dB and with the MediaPlayer volume knob maxed out too, I still can barely hear sound. I tried rebooting to win-xp, and there it works, but the volume is not remembered: when rebooting back to Haiku the audio volume returns back to very low.

[ttcoder]

listdev:

device Multimedia controller (Audio device) [4|3|0]
  vendor 8086: Intel Corporation
  device 284b: 82801H (ICH8 Family) HD Audio Controller

And it so happens that I waited until finding (a) culprit, before filing this ticket. As of tonight, after a few weeks of fiddling with the HDA driver, I now have FULL volume in Haiku. Here's the diff I applied:

~/Desktop/haiku_GIT/hda> diff hda_codec_ORIGINAL.cpp hda_codec.cpp 
1040c1041,1042
<       if (!hda_audio_group_build_output_tree(audioGroup, true)) {
---
> //    if (!hda_audio_group_build_output_tree(audioGroup, true))
>       {

This of course cannot be commited as-is to the source-tree, but hopefully it will help find the root cause.. :-)

Looking at the syslog, I see that the hda-mixer has a 'offset' that differs' from its 'number of steps' (20 vs. 43).. noticed that this is atypical of the other entries listed in the syslog, though dunno if it's significant for sure..:

KERN: 23: Audio mixer
KERN: 	Supported power states: D0 D1 D2 D3 
KERN: 	[Power] [Conn. list] [Amplifier override] [In amplifier] [Stereo] 
KERN: 	In Amp: supports mute, step size: 1.5 dB, # steps: 43, offset to 0 dB: 20 (0x80052B14)
KERN: 	Inputs: 25 20 18 17 21 

I'm available for questions, tests ..etc that could help fix this for good.

Thanks.

[korli]

Your patch actually bypasses the mixer to find the output path. It would be interesting to compare syslogs with and without the patch.

The driver tries to configure widgets along the output path in hda_audio_group_get_widgets(). There each call to hda_send_verbs() changes something on a widget. You could try to comment one after the other to check if you have the normal behaviour.

Hope this helps.

[ttcoder]

Replying to korli:

The driver tries to configure widgets along the output path in hda_audio_group_get_widgets(). There each call to hda_send_verbs() changes something on a widget. You could try to comment one after the other to check if you have the normal behaviour.

Hmmm I'm coming back to you mostly empty-handed on this:

• with the previous "activated mixer" source I commented out the hda_send_verbs() calls one by one until all 5 were out, but sound was active, yet very quiet, in all cases.
• then I did again the "bypass mixer" line change, with the five hda_send_verbs() still all commented out, and volume came back full, working correctly!

Your patch actually bypasses the mixer to find the output path. It would be interesting to compare syslogs with and without the patch.

Here's the syslog difference, edited for clarity:

~/Desktop/New folder> diff hda_log hda_log_patcheddriver > fullvolume.diff

Results in this:

87c87,88
< KERN: build output tree: use mixer
---
> KERN: try without mixer!
> KERN: build output tree: don't use mixer
89,94c90,92
< KERN:     try widget 25: 0x82096a0c
< KERN:     try widget 23: 0x820968b4
< KERN:     widget 23 is candidate
< KERN:         output: added output widget 25
< KERN:       output: added mixer/selector widget 23
---
> KERN:     try widget 25: 0x8209380c
> KERN:     widget 25 is candidate
> KERN:       output: added output widget 25
97,99c95,97
< KERN:     try widget 25: 0x82096a0c
< KERN:     try widget 23: 0x820968b4
< KERN:     widget 23 is candidate
---
> KERN:     try widget 25: 0x8209380c
> KERN:     widget 25 is candidate
> KERN:       output: added output widget 25
104c101
< KERN:     try widget 23: 0x820968b4
---
> KERN:     try widget 23: 0x820936b4
119,120c116,117
< KERN: 	Inputs: 25 <23> 
---
> KERN: 	Inputs: <25> 23 
125,126c122,123
< KERN: 	Inputs: 25 <23> 
---
> KERN: 	Inputs: <25> 23 
153,154c150,151
< KERN: 	Inputs: <25> 20 18 17 21 
---
> KERN: 	Inputs: 25 <20> 18 17 21 
164c161
---
176d172
< KERN: UNMUTE/SET INPUT GAIN widget 23 (offset 20)

I notice that..

• the gain is set twice on the mixer in the failure case, and only once in the "bypass mixer" case. (ref. line "UNMUTE/SET INPUT GAIN widget 23")
• the "try widget 23: 0x820968b4" hex value differs in the first and second case
• my hardware seems to have "quirks" enabled ("KERN: input vref 80 enabled")

Can't interpret any of those oddities... Hopefully it's more clear for you than for me ;-)

[ttcoder]

Volume too quiet

[ttcoder]

Volume normal, when the Mixer Is Bypassed

[korli]

Looks OK. How does the media preferences output panel look like?

The enumeration of which controls are created isn't in the log. Could you please activate tracing in hda_multi_audio.cpp?

[ttcoder]

Media Prefs look a little odd with HDA-mixer bypassed...

[ttcoder]

Tracing enabled in hda_multi_audio.cpp

[ttcoder]

Tracing enabled in hda_multi_audio.cpp

[ttcoder]

Tracing enabled in hda_multi_audio.cpp

[ttcoder]

(apologies for the two duplicates; my bad for using the "back" button of W+ and there is no way to delete attached files..)

The media prefs look different from usual with the 'patched' driver indeed; and they remain odd-looking even after an extra media_server restart. I tried the Speaker sliders and they are functional when dragged though:

I guess the extra tracing will give more info too.

[korli]

in hda_codec.cpp line 1327, could you try to replace AMP_CAP_OFFSET(widget.capabilities.input_amplifier) with AMP_CAP_NUM_STEPS(widget.capabilities.input_amplifier) not bypassing the mixer?

The code sets the gain to 0dB by default. With this change it would max out the gain.

[ttcoder]

No luck..

Modified like thus:

//	| AMP_CAP_OFFSET(widget.capabilities.input_amplifier));
	| AMP_CAP_NUM_STEPS(widget.capabilities.input_amplifier));

And to be sure the code was called I also modified the TRACE() above, which indeed got me this in the syslog:

KERN: UNMUTE/SET INPUT GAIN widget 23 (offset 43)

By opposed to the value returned before the change:

KERN: UNMUTE/SET INPUT GAIN widget 23 (offset 20)

I suppose it would be helpful to try other combinations, propagate this change to "SET OUTPUT GAIN" verbs maybe?, tell me if that'd help.

[ttcoder]

Still quiet audio with CAP_NUM_STEPS macro; played with media sliders a bit at the end

[ttcoder]

@korli - Found it! Found why the mixer is so quiet, and a one-liner "fix" (so now I can more credibly call for this ticket being closed in the near future I guess ;-).

The quietness of the mixer does not come from the initial hardware setup, it is due to the configuration done at the very end inside hda_multi_audio.cpp, which generates these lines in the syslog:

KERN: set_mix: 23 mixer: 0
KERN: set_mix: 23 mixer unmuting 0 (1737000)
KERN: set_mix: 23 mixer   muting 1 (1737100)
KERN: set_mix: 23 mixer   muting 2 (1737200)
KERN: set_mix: 23 mixer   muting 3 (1737300)
KERN: set_mix: 23 mixer   muting 4 (1737400)

After some trial and error I've found out that if I insert this line in the middle of the set_mix() for() loop:

verb[j]=0;

everything is in order again: I have a normal audio volume... AND I believe this has fixed the Line-In bug (#8333) for me also. To wit, with this zero-verb line added I really was able to roll back all the other changes, roll back the mixer bypass and the AMP_CAP_OFFSET changes ..etc, such that running "git diff" yields this and only this:

/boot/common/cache/tmp/....haiku..../haiku/src/add-ons/kernel/drivers/audio/hda> git diff
diff --git a/src/add-ons/kernel/drivers/audio/hda/hda_multi_audio.cpp b/src/add-ons/kerne
index 14fcd56..377ed88 100644
--- a/src/add-ons/kernel/drivers/audio/hda/hda_multi_audio.cpp
+++ b/src/add-ons/kernel/drivers/audio/hda/hda_multi_audio.cpp
@@ -801,6 +801,7 @@ set_mix(hda_audio_group* audioGroup, multi_mix_value_info * mmvi)
                                        | AMP_SET_LEFT_CHANNEL | AMP_SET_RIGHT_CHANNEL
                                        | AMP_SET_INPUT_INDEX(j)
                                        | ((mmvi->values[i].mux == j) ? 0 : AMP_MUTE));
+verb[j]=0;
                                TRACE("set_mix: %ld mixer %smuting %ld (%lx)\n", control-
                                        (mmvi->values[i].mux == j) ? "un" : "", j, verb[j
                        }
/boot/common/cache/tmp/....haiku..../haiku/src/add-ons/kernel/drivers/audio/hda> git status
# On branch master
#
(..)

I've also tried to comment out the whole block but IIRC things don't work as well as they do when sending '0' verbs as above.

So what is the purpose of that whole AMP_SET_INPUT,AMP_SET_LEFT_CHANNEL business ..etc ? And do you want me to try some other changes to track this down more thoroughly ? Thanks.

[korli]

This section is about B_MIX_MUX_MIXER which represents a combobox/selector in the Media preferences. The code unmutes the selected input (the index is the value mmvi->values[i].mux), and mutes other inputs.

This B_MIX_MUX_MIXER is supposed to be used for the input mixer, selecting only one input. Do you happen to have an input selector on the input panel?

A more correct fix would be not avoid using the mixer on the input path (untested):

diff --git a/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp b/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp
index 74de641..dacfaf5 100644
--- a/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp
+++ b/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp
@@ -897,7 +920,8 @@ hda_widget_find_input_path(hda_audio_group* audioGroup, hda_widget* widget,
        switch (widget->type) {
                case WT_PIN_COMPLEX:
                        // already used
-                       if (widget->flags & WIDGET_FLAG_INPUT_PATH)
+                       if ((widget->flags & (WIDGET_FLAG_INPUT_PATH 
+                                       | WIDGET_FLAG_OUTPUT_PATH)) != 0)
                                return false;
 
                        if (PIN_CAP_IS_INPUT(widget->d.pin.capabilities)) {
@@ -917,7 +941,8 @@ TRACE("      %*sinput: added input widget %ld\n", (int)depth * 2, "", widget->no
                case WT_AUDIO_SELECTOR:
                {
                        // already used
-                       if (widget->flags & WIDGET_FLAG_INPUT_PATH)
+                       if ((widget->flags & (WIDGET_FLAG_INPUT_PATH 
+                                       | WIDGET_FLAG_OUTPUT_PATH)) != 0)
                                return false;
 
                        // search for pin complex in this path

[ttcoder]

@korli: that patch brings line-in/mic-in to 100% perfection! Though for some reason there still needs to be verb-zero'ing as well (BTW I've found out only one zero is needed, see below)... I've tested with/without verb zeroing and with/without the above patch, here's the results of the interesting combinations:

• withOUT the above diff and with zeroed verb: playback is perfect, and microphone-in works but strangely, I have to unmute it in both the Input pane and Output pane of the Media preflet, otherwise SoundRecorder receives nothing. That's odd because SoundRecorder should only be affected by "Input" settings, and that's annoying because you hear youself in the loudspeakers as you speak in the microphone :-].. So verb zeroing alone was not enough.
• with the above diff but withOUT zeroed verb: playback is muted, but input works somewhat now (IIRC one has to shout loudly into the mike). So the above patch alone is not enough.
• with the above diff and with zeroed verb: playback is perfect (even more loud/clear than when the HDA mixer is bypassed), and input as well, meaning ticket #8333 is thoroughly fixed for me as well: sound is loud and clear, and I just have to unmute Mic-in in the "Input" pane of media prefs, I do not have to unmute it in the Output pane. Perfection everywhere.

I've narrowed down the verb zero'ing though, I've realized it's sufficient to zero out only the first, at index j=0. I'll do some cold-boot testing in case behavior differs from a media_server warm restart but here I doubt it has an impact:

if(j==0) verb[j]=0;

Resulting in this syslog'ging:

KERN: hda: set_mix: 23 mixer: 3
KERN: hda: set_mix: 23 mixer muting 0 (0)
KERN: hda: set_mix: 23 mixer muting 1 (1737180)
KERN: hda: set_mix: 23 mixer muting 2 (1737280)
KERN: hda: set_mix: 23 mixer unmuting 3 (1737300)
KERN: hda: set_mix: 23 mixer muting 4 (1737480)
KERN: hda: Setting mixer 3 failed on widget 23!

Note the "failed on widget..." last line; it appeared today or maybe yesterday; I've only noticed it now. Does not seem to impact things anyway, apart from the need to tick/untick some checkboxes sometimes (their state seems to vary from session to session) everything is perfect.

EDIT: also the "unmuting" word seems to take a stroll from line to line every time I run a test: here it's on line 3 but sometimes it's line 2 or 1, though maybe it's simply behavior related to the 'mute' checkboxes not being always in the same state..

So I guess now the question is, why does "set_mix: 23 mixer muting 0" mess up the output (and quiets down the input IIRC) ?

[korli]

Could you post a relevant syslog with the diff applied and images of the Media preferences input and output panels?

These set_mix calls are done by the media server when trying to apply the saved configuration for the multiaudio node. I'm unsure it's correct when changing the driver code and the exposed widgets. You would need to delete the multi_audio configuration in this case to be sure.

The important part in the code is the parser which traverses the widget tree; in the syslog around the lines "build output tree" and "build input tree". In my opinion the node 23 shouldn't appear any more on the input path, so no widget for it in the Input panel, so no saved configuration applied on start up.

[ttcoder]

The 'multi_audio configuration' is ~/config/settings/ System Audio Mixer right ? This sounded like a possible culprit so I tried an experiment: delete the file, and make sure it stays out of the way (indeed it's not recreated unless I re-open the media preflet ..etc). Then I ran the driver without the zero verb: no audio. Finally I re-enabled my zero-verb hack (with the System Audio Mixer settings still not there) and I had normal audio. So the off-by-one problems (I think you are right and there are some indeed, since I always have to juggle with sliders and stuff when restarting the driver) are probably just a side-show, but not the central problem.

There is another oddity though: if I do not recreate the System Audio Mixer settings file, the HDA driver (presumably on orders from media_server) goes on a "rotation" of muting: each time it is launched it will unmute a different mixer input. So for example, the very first driver/media_server restart after deleting System Audio Mixer goes like this, it unmutes at index 0:

KERN: hda: set_mix: 23 mixer: 0
KERN: hda: set_mix: 23 mixer unmuting 0 (0)
KERN: hda: set_mix: 23 mixer muting 1 (1737180)
KERN: hda: set_mix: 23 mixer muting 2 (1737280)
KERN: hda: set_mix: 23 mixer muting 3 (1737380)
KERN: hda: set_mix: 23 mixer muting 4 (1737480)

Then on the second restart (quit media_server, overwrite driver, restart media), it unmutes at index 1:

KERN: hda: set_mix: 23 mixer: 1
KERN: hda: set_mix: 23 mixer muting 0 (0)
KERN: hda: set_mix: 23 mixer unmuting 1 (1737100)
KERN: hda: set_mix: 23 mixer muting 2 (1737280)
KERN: hda: set_mix: 23 mixer muting 3 (1737380)
KERN: hda: set_mix: 23 mixer muting 4 (1737480)

And so on and so forth. When rolling over index 4 it returns to index 0 and starts over. Not sure what that means. Then if I recreate the settings file things stabilize again.

The "Input" tab looks like this, nothing too peculiar:

The Mixer/23 is indeed skipped when building the input path now, such that Input/26 will be directly connected to JackIn/20:

KERN: build input tree
KERN:   look at input widget 26 (5 inputs)
KERN:     try widget 23: 0x82094ab4
KERN:     widget 23 is candidate
KERN:     try widget 20: 0x820948b0
KERN:     widget 20 is candidate
KERN:       input: added input widget 20
KERN:     add pin widget 26

So it's not the reason why the mixer is being configured like this in set_mix():

KERN: hda: set_mix: 23 mute: 0
KERN: hda: set_mix: sending verb to 23: 0 14 1 6114
KERN: hda: set_mix: ctrl2 sending verb to 23: 0 14 1
KERN: hda: set_mix: 23 gain: 2b and 23 gain: 0
KERN: hda: set_mix: sending verb to 23: 0 2b 1 612b
KERN: hda: set_mix: ctrl2 sending verb to 23: 0 0 1
KERN: hda: set_mix: 23 mute: 80
(..)
KERN: hda: set_mix: 23 mixer: 1
KERN: hda: set_mix: 23 mixer muting 0 (0)
KERN: hda: set_mix: 23 mixer unmuting 1 (1737100)
KERN: hda: set_mix: 23 mixer muting 2 (1737280)
KERN: hda: set_mix: 23 mixer muting 3 (1737380)
KERN: hda: set_mix: 23 mixer muting 4 (1737480)

I guess it's rather because of the "Output" side of the equation ?? (Mixer/23 is used as the main mixer in the Output Path in this case; to recap the story of this bug: my initial "fix" for this quiet-Lenovo bug was to bypass Mixer/23 completely; now I've discovered that I can re-add Mixer/23 in the OutputPath so long as I comment out one of the set_mixer() actions).

syslog coming up next !

====

Side Note -- while playing with media preflet I noticed an odd muting bug: it relates to the checkboxes and sliders and their contradicting each other -- I see it with the "Speaker" column and the "Left Mic In" columns, though I guess that bug could also be reproduced with the others. The bug has two mirror aspects that go like this:

• tick the "Mute" checkbox of (for example) "Speaker". The loudspeakers go mute. Now move the sliders up and down slightly and... the speakers un-mute themselves, even though the Mute checkbox is still ticked !
• now with the "Mute" checkbox still ticked and audio still coming through, click that checkbox to make the blue cross disappear and... the speakers go mute again, even though the "Mute" checkbox is not ticked any more! (in other words it behaves like a toggle regardless of its state).

I guess this should be filed as a separate ticket (no relation to this "quiet Lenovo" bug here since the quietness remains no matter how hard I bang the media preflet sliders and stuff =8-).. But not sure if this should be filed against the media preflet or media_server of it it's HDA specific; I should try that scenario on my Soundblaster Live PC and I'll know for sure.

Here's the screengrab again, as a visual support for the above explanations:

[ttcoder]

Now for something VERY odd (and with a little luck, I'm getting closer to the root problem here): if I remove my "zero verb" hack and do this hack instead:

-	| ((mmvi->values[i].mux == j) ? 0 : AMP_MUTE));
+	| ((mmvi->values[i].mux == j) ? 0 : 0));

Then I get a situation "inbetween": instead of being completely disabled, the audio output is "quiet", like the baseline HDA driver in trunk does. That is, it is quiet after fiddling with media preflet sliders (they are out of whack again, so I need to unmute ..etc).

This results in the following:

KERN: hda: set_mix: 23 mixer: 2
KERN: hda: set_mix: 23 mixer muting 0 (1737000)
KERN: hda: set_mix: 23 mixer muting 1 (1737100)
KERN: hda: set_mix: 23 mixer unmuting 2 (1737200)
KERN: hda: set_mix: 23 mixer muting 3 (1737300)
KERN: hda: set_mix: 23 mixer muting 4 (1737400)

(i.e. the 0x80 for "unmuting 2" has been hacked away, resulting in a straight 1737200 value/verb). If sending 0x80 to input 3, or 4, it will still mute input 0 (speakers).

To re-iterate,

using 0x80 anywhere, even on ANOTHER input than 0 (which corresponds to widget Speakers/16) will cancel out the sound on Speakers/16 (as well as on microphone-in IIRC) ! It's like we are setting a magic "be quiet" bit on the mixer or something.

====

This is a 2007 laptop, with HDA hardware conforming to HDA 1.0.1, whereas the HDA specs are up to 1.0.3+ now. Could it be that my HDA chipset does not understand the flags passed to it, mis-interprets them as "quiet down the sound" or something ?

Here's the code with the flags again:

				verb[j] = MAKE_VERB(audioGroup->codec->addr,
					control->nid, VID_SET_AMPLIFIER_GAIN_MUTE, AMP_SET_INPUT
					| AMP_SET_LEFT_CHANNEL | AMP_SET_RIGHT_CHANNEL
					| AMP_SET_INPUT_INDEX(j)
					| ((mmvi->values[i].mux == j) ? 0 : AMP_MUTE));

[ttcoder]

Only applied the diff, and minor changes to TRACE()ing, no hack: I have no audio output at all then

[korli]

AMP_SET_INPUT is a bit which is documented in ​http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/high-definition-audio-specification.pdf page 146. It tells the controller which "amp" is actually to be set, the input amp or the output amp. The code looks correct.

The corresponding code in FreeBSD is here: ​http://fxr.watson.org/fxr/source/dev/sound/pci/hda/hdaa.c?im=excerpts#L1258

The node 23 shouldn't expose a widget in the input panel, as it's not related to input. It should instead expose a mux widget for the node 26. I'll investigate the code at ​http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/audio/hda/hda_multi_audio.cpp#n546

As expected the widget tree parser still needs a bit of work :)

[korli]

Please check with hrev44591.

[ttcoder]

Output works perfectly after a git pull to retrieve hrev44591, no need for any hack now :-) ("git diff" comes up empty).

So that was it indeed: on some hda configs, the code was confusing the main mixer for line-in and banging on it in the wrong way, muting the speakers and/or input (#8333 is fixed for me too) indeed. The odd behavior of the slider versus. mute checkbox is gone too now, so it was just a side-effect of my hacks.

Looks like I made you go hunting for docs with my erroneous assumptions... But it won't be wasted, I bookmarked those and already started using the doc for working on #8476, thank you Jerôme.

Please close as fixed.

[korli]

Thank you for the feedback

[axeld]

Just to make things a bit more complicated: I do not have any sound anymore after hrev44591 (font speakers, headphones still work -- I do suffer from #8949, though). If I undo the changes in hda_widget_find_input_path() I get sound from the speakers again.

ttcoder: does the patch still work for you after undoing those changes as well?

[ttcoder]

It appears it does! However there is another regression with that change, namely #8333 is back (line-in/microphone-in no longer works). (maybe I should cross-post this comment there for that matter hmm)

In other words,

• I did a git pull to be up to date, rebuilt to ensure there's no regression or anything.
• I then applied these changes (I think these are what you are referring to axel):

@@ -947,7 +947,7 @@ hda_widget_find_input_path(hda_audio_group* audioGroup, hda_widget* widget,
                case WT_PIN_COMPLEX:
                        // already used
                        if ((widget->flags
-                                       & (WIDGET_FLAG_INPUT_PATH | WIDGET_FLAG_OUTPUT_PATH)) != 0)
+                                       & (WIDGET_FLAG_INPUT_PATH/* | WIDGET_FLAG_OUTPUT_PATH*/)) != 0)
                                return false;
 
                        if (PIN_CAP_IS_INPUT(widget->d.pin.capabilities)) {
@@ -968,7 +968,7 @@ TRACE("      %*sinput: added input widget %ld\n", (int)depth * 2, "", widget->no
                {
                        // already used
                        if ((widget->flags
-                                       & (WIDGET_FLAG_INPUT_PATH | WIDGET_FLAG_OUTPUT_PATH)) != 0)
+                                       & (WIDGET_FLAG_INPUT_PATH/* | WIDGET_FLAG_OUTPUT_PATH*/)) != 0)
                                return false;

and then line-in no longer works (though sound output is unchanged, still good).

Maybe running a "diff" on the syslog with and without the change could give direct hints (on my syslog and/or yours I guess) on why it triggers a regression of ticket #8333 and a progression for you..

[ttcoder]

@axel -- Out of curiosity, the progression we are talking about, is a fix for your HDMI audio to external speakers, not a fix for the "choppy audio unless playing video fullscreen" part of #8949 IIUC ?

[axeld]

The fix is that I get sound out of the speakers (HDMI is still silent, but that will probably need more driver support). I don't really understand why this change does anything for the output, but well.

[axeld]

Axel's HDA widget connections in Linux

[ttcoder]

Can't view the .svg in either W+ or ShowImage, it insists on opening as text even if I force the MIME type; I still have to upgrade my haiku install to a recent image though, maybe mine's too old for SVG.

Anyhow from what I remember when working with/learning HDA from/ korli, the relevant part of the syslog would be "build input tree"; which in ​your syslog looks like this:

271 KERN: build input tree
272	KERN:   look at input widget 16 (1 inputs)
273	KERN:     try widget 30: 0x828f4ec8
274	KERN:     widget 30 is candidate
275	KERN:         input: added input widget 44
276	KERN:       input: added mixer/selector widget 30
277	KERN:         input: added input widget 43
278	KERN:       input: added mixer/selector widget 30
279	KERN:         input: added input widget 42
280	KERN:       input: added mixer/selector widget 30
281	KERN:         input: added input widget 41
282	KERN:       input: added mixer/selector widget 30
283	KERN:         input: not added mixer/selector widget 33
284	KERN:     add pin widget 16
285	KERN:   look at input widget 17 (1 inputs)
286	KERN:     try widget 31: 0x828f4f74
287	KERN:     widget 31 is candidate
288	KERN:         input: not added mixer/selector widget 33
289	KERN:       input: not added mixer/selector widget 31
290	KERN:   look at input widget 19 (1 inputs)
291	KERN:     try widget 47: 0x828f5a34
292	KERN:     widget 47 is candidate
293

I cross-checked with the "build output tree" section but the only common node is 33... except it's not in fact used in the output tree for you, so I don't see how build-input could mess up your output..

It would likely help much if you post a syslog of the functioning hda driver (the one compiled without the "OUTPUT_PATH_..." stuff), so as to compare it with the above non-working one..

[axeld]

Today it's working with the unchanged driver. I'm a bit clueless, but it looks like it's pretty erratic here, so I guess you can safely ignore my comment to this ticket.