Bug 87002

Created attachment 110457 [details]
Output of pactl list

Created attachment 110458 [details]
Verbose output on the 1st run (no local configuration stored)

Created attachment 110459 [details]
Verbose output on the 2nd run (headphones unplugged but still selected)

seem only one physical  jack 

is this jack support headset , headphone/mic ?

sys/class/sound/hwC0D0/init_pin_configs:
0x12 0x40000000
0x14 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x40541a05
0x1e 0x411111f0
0x21 0x04211010

/sys/class/sound/hwC0D0/driver_pin_configs:
0x19 0x04a110f0


driver fixup pin 0x19

Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Master Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Headphone Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x0001001c: OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x04211010: [Jack] HP Out at Ext Right
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x0c* 0x0d

Simple mixer control 'Mic',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-34.50dB] [off]
  Front Right: Playback 0 [0%] [-34.50dB] [off]


if the jack suport headphone or mic ? mic playback volume control is no use

Thanks for taking a look to this, and the quick feedback

See my comments/answers inline below, hope they are helpful too

(In reply to Raymond from comment #4)
> seem only one physical  jack 
> 
> is this jack support headset , headphone/mic ?

It supports both headset and headphone/mic connectors.

> sys/class/sound/hwC0D0/init_pin_configs:
> 0x12 0x40000000
> 0x14 0x411111f0
> 0x17 0x411111f0
> 0x18 0x411111f0
> 0x19 0x411111f0
> 0x1a 0x411111f0
> 0x1b 0x411111f0
> 0x1d 0x40541a05
> 0x1e 0x411111f0
> 0x21 0x04211010
> 
> /sys/class/sound/hwC0D0/driver_pin_configs:
> 0x19 0x04a110f0
> 
> driver fixup pin 0x19
> 

Sorry, I'm new to the audio world, and I'm not sure I understand what you mean, or the relationship with the excerpt below (should it be the one for Node 0x19, perhaps?)

> Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
>   Control: name="Master Playback Switch", index=0, device=0
>     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>   Control: name="Headphone Jack", index=0, device=0
>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>   Amp-Out vals:  [0x00 0x00]
>   Pincap 0x0001001c: OUT HP EAPD Detect
>   EAPD 0x2: EAPD
>   Pin Default 0x04211010: [Jack] HP Out at Ext Right
>     Conn = 1/8, Color = Black
>     DefAssociation = 0x1, Sequence = 0x0
>   Pin-ctls: 0xc0: OUT HP
>   Unsolicited: tag=02, enabled=1
>   Power states:  D0 D1 D2 D3 EPSS
>   Power: setting=D0, actual=D0
>   Connection: 2
>      0x0c* 0x0d

(In reply to Raymond from comment #5)
> Simple mixer control 'Mic',0
>   Capabilities: pvolume pswitch penum
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 31
>   Mono:
>   Front Left: Playback 0 [0%] [-34.50dB] [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off]
> 
> 
> if the jack suport headphone or mic ? mic playback volume control is no use

The jack supports both, but at the time I took this log I had a simple headset (no mic) connected

http://www.gigabyte.com/products/product-page.aspx?pid=5038

are yours revision 1.0 ?

seem support headphone or mic 

the icon is not headset but


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=9dc12862da9d56ef4da646ba540c4f58b78738fc

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=73bdd597823e2231dc882577dbbaf8df92fe1775




+	[ALC283_FIXUP_BXBT2807_MIC] = {
+		.type = HDA_FIXUP_PINS,
+		.v.pins = (const struct hda_pintbl[]) {
+			{ 0x19, 0x04a110f0 },
+			{ },
+		},
+	},

the current implemenation use sequence number to identify headset mic and headphone mic but it still   use sequence number zero

http://voices.canonical.com/david.henningsson/2014/03/07/headset-jacks-on-newer-laptops/

can your codec detect the jack type automatically or not ?


http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/media-keys/what-did-you-plug-in/pa-backend.c

In PulseAudio ports will show up with the following names:
   Headphones - analog-output-headphones
   Headset mic - analog-input-microphone-headset
   Jack in mic-in mode - analog-input-microphone

   However, since regular mics also show up as analog-input-microphone,
   we need to check for certain controls on alsa mixer level too, to know
   if we deal with a separate mic jack, or a multi-function jack with a 
   mic-in mode (also called "headphone mic"). 
   We check for the following names:

   Headphone Mic Jack - indicates headphone and mic-in mode share the same jack,
     i e, not two separate jacks. Hardware cannot distinguish between a
     headphone and a mic.
   Headset Mic Phantom Jack - indicates headset jack where hardware can not
     distinguish between headphones and headsets
   Headset Mic Jack - indicates headset jack where hardware can distinguish
     between headphones and headsets. There is no use popping up a dialog in
     this case, unless we already need to do this for the mic-in mode.

yours seem different from pa_backend.c

Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Mic Jack", index=0, device=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
  Amp-In vals:  [0x00 0x00]
  Pincap 0x00003724: IN Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
  Control: name="Mic Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=1, ofs=0
  Control: name="Mic Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=1, ofs=0
  Control: name="Beep Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Control: name="Beep Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
  Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
  Connection: 5
     0x18 0x19 0x1a 0x1b 0x1d


why did the driver create beep playback volume/switch when node 0x1d is [N/A]

Node 0x1d [Pin Complex] wcaps 0x400400: Mono
  Pincap 0x00000020: IN
  Pin Default 0x40541a05: [N/A] Digital Out at Ext N/A
    Conn = RCA, Color = Black
    DefAssociation = 0x0, Sequence = 0x5
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

Unsolicited: tag=02, enabled=1

Unsolicited: tag=01, enabled=1

it is strange to enable unsolicited event on two nodes when you only have one physical jack


try hda jack sense test

Again, thanks a lot for your time. See my answers below, at least in the places where I could certainly provide one! :)

Feel free to ask me to conduct more experiments

(In reply to Raymond from comment #7)
> http://www.gigabyte.com/products/product-page.aspx?pid=5038
> 
> are yours revision 1.0 ?
>

Yes

> seem support headphone or mic 
> 
> the icon is not headset but
> 
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/
> pci/hda?id=9dc12862da9d56ef4da646ba540c4f58b78738fc

I just plugged a Philips SHE8005 Headset[1] (same jack combined) that I have, and I can confirm that is properly recognized as both and output and input device.


(In reply to Raymond from comment #8)
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/
> pci/hda?id=73bdd597823e2231dc882577dbbaf8df92fe1775
> 
> 
> 
> 
> +	[ALC283_FIXUP_BXBT2807_MIC] = {
> +		.type = HDA_FIXUP_PINS,
> +		.v.pins = (const struct hda_pintbl[]) {
> +			{ 0x19, 0x04a110f0 },
> +			{ },
> +		},
> +	},
> 
> the current implemenation use sequence number to identify headset mic and
> headphone mic but it still   use sequence number zero

Not sure what you mean here. I'm CCing my colleague Daniel Drake (author of the other kernel commit you pointed out), in case he can maybe comment on this 


(In reply to Raymond from comment #9)
> http://voices.canonical.com/david.henningsson/2014/03/07/headset-jacks-on-
> newer-laptops/
> 
> can your codec detect the jack type automatically or not ?

I'm using codec ALC283 and yes, the jack type seems to be automatically detected when plugging it


(In reply to Raymond from comment #10)
> 
> 
> In PulseAudio ports will show up with the following names:
>    Headphones - analog-output-headphones
>    Headset mic - analog-input-microphone-headset
>    Jack in mic-in mode - analog-input-microphone
> 
>    However, since regular mics also show up as analog-input-microphone,
>    we need to check for certain controls on alsa mixer level too, to know
>    if we deal with a separate mic jack, or a multi-function jack with a 
>    mic-in mode (also called "headphone mic"). 
>    We check for the following names:
> 
>    Headphone Mic Jack - indicates headphone and mic-in mode share the same
> jack,
>      i e, not two separate jacks. Hardware cannot distinguish between a
>      headphone and a mic.
>    Headset Mic Phantom Jack - indicates headset jack where hardware can not
>      distinguish between headphones and headsets
>    Headset Mic Jack - indicates headset jack where hardware can distinguish
>      between headphones and headsets. There is no use popping up a dialog in
>      this case, unless we already need to do this for the mic-in mode.

This is I can see from the verbose output of pulseaudio -vvvvv, when plugging that Philips headset:

   [pulseaudio] module-alsa-card.c: Jack 'Headphone Jack' is now plugged in
   [pulseaudio] module-alsa-card.c: Jack 'Mic Jack' is now plugged in


(In reply to Raymond from comment #11)
> Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
>   Control: name="Mic Playback Volume", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=1, ofs=0
>   Control: name="Mic Playback Switch", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=1, ofs=0
>   Control: name="Beep Playback Volume", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=4, ofs=0
>   Control: name="Beep Playback Switch", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=4, ofs=0
>   Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
>   Amp-In vals:  [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80]
>   Connection: 5
>      0x18 0x19 0x1a 0x1b 0x1d
> 
> why did the driver create beep playback volume/switch when node 0x1d is [N/A]
> 

Can't really answer this question, sorry :(

> Node 0x1d [Pin Complex] wcaps 0x400400: Mono
>   Pincap 0x00000020: IN
>   Pin Default 0x40541a05: [N/A] Digital Out at Ext N/A
>     Conn = RCA, Color = Black
>     DefAssociation = 0x0, Sequence = 0x5
>   Pin-ctls: 0x20: IN
>   Power states:  D0 D1 D2 D3 EPSS
>   Power: setting=D0, actual=D0

(In reply to Raymond from comment #12)
> Unsolicited: tag=02, enabled=1
> 
> Unsolicited: tag=01, enabled=1
> 
> it is strange to enable unsolicited event on two nodes when you only have
> one physical jack
> 

Perhaps that's a mistake, I really don't know. Could you elaborate a bit more on that?

> try hda jack sense test

I did, see the output before and after unplugging the Philips headset:

    $ sudo hda-jack-sense-test 
    Pin 0x21 (Black HP Out): present = No

    $ sudo hda-jack-sense-test 
    Pin 0x21 (Black HP Out): present = Yes


[1] http://www.philips.co.uk/c-p/SHE8005_10/-/specifications

Ok, I've looked at this issue now. 

The startup order is something like:

1) module_alsa_card's init_jacks initializes port availability, and for every port, we get a callback to port_available_hook_callback. No action is done here due to the fix for bug 73375.

2) module_alsa_card's init_profile is called, which in turn creates sources and sinks. At this point, we don't switch profiles: our current profile is analog, we don't switch away from profiles when ports become unavailable.

The thing is, to solve this properly, we should need a callback *between* 1) and 2). We can't act on 1), because not all ports are guaranteed to have its availability set yet. But acting on 2) is too late, because then the profile is already set.

(In reply to David Henningsson from comment #14)
> Ok, I've looked at this issue now. 
> 
> The startup order is something like:
> 
> 1) module_alsa_card's init_jacks initializes port availability, and for
> every port, we get a callback to port_available_hook_callback. No action is
> done here due to the fix for bug 73375.
> 
> 2) module_alsa_card's init_profile is called, which in turn creates sources
> and sinks. At this point, we don't switch profiles: our current profile is
> analog, we don't switch away from profiles when ports become unavailable.
> 
> The thing is, to solve this properly, we should need a callback *between* 1)
> and 2). We can't act on 1), because not all ports are guaranteed to have its
> availability set yet. But acting on 2) is too late, because then the profile
> is already set.

What about letting 1) and 2) to finish, as if everything went fine and then, as a last and desperate attempt to avoid having a profile with no ports available, check if there's a better option and switch profiles if needed?

That's the "hack" I've been experimenting with lately in this device (notice that we use PA 5.0, but an stable release, not the trunk), and so far seemed to work fine, although I'm not 100% it's a totally broken or not.

You can check it in this commit: https://github.com/mariospr/pulseaudio/commit/4d3fdd5bbe8bc003f98403188e38a02110ba4c91

Please let me know what you think

Thanks a lot for the feedback!

(In reply to Mario Sanchez Prada from comment #15)
> (In reply to David Henningsson from comment #14)
> > Ok, I've looked at this issue now. 
> > 
> > The startup order is something like:
> > 
> > 1) module_alsa_card's init_jacks initializes port availability, and for
> > every port, we get a callback to port_available_hook_callback. No action is
> > done here due to the fix for bug 73375.
> > 
> > 2) module_alsa_card's init_profile is called, which in turn creates sources
> > and sinks. At this point, we don't switch profiles: our current profile is
> > analog, we don't switch away from profiles when ports become unavailable.
> > 
> > The thing is, to solve this properly, we should need a callback *between* 1)
> > and 2). We can't act on 1), because not all ports are guaranteed to have its
> > availability set yet. But acting on 2) is too late, because then the profile
> > is already set.
> 
> What about letting 1) and 2) to finish, as if everything went fine and then,
> as a last and desperate attempt to avoid having a profile with no ports
> available, check if there's a better option and switch profiles if needed?
> 
> That's the "hack" I've been experimenting with lately in this device (notice
> that we use PA 5.0, but an stable release, not the trunk), and so far seemed
> to work fine, although I'm not 100% it's a totally broken or not.
> 
> You can check it in this commit:
> https://github.com/mariospr/pulseaudio/commit/
> 4d3fdd5bbe8bc003f98403188e38a02110ba4c91
> 
> Please let me know what you think
> 
> Thanks a lot for the feedback!

Well, it's a hack. And the hackier, the more likely we regress some other use case.

I'm more thinking that maybe one could initialize the port availability earlier, even before pa_card_new, using the pa_device_port_new_data_set_available function. Then we could act accordingly already in the callback in 1).

(In reply to David Henningsson from comment #16)
> [...]
> Well, it's a hack. And the hackier, the more likely we regress some other
> use case.

Agreed. I never thought of that as a solution but more as an experiment, hopefully able to spark some discussion. Seems it worked, pretty nicely from that pov :)

Anyway, I'm building PA again enabling the unit tests, to at least check whether I'm regressing something obvious..

> I'm more thinking that maybe one could initialize the port availability
> earlier, even before pa_card_new, using the
> pa_device_port_new_data_set_available function. Then we could act
> accordingly already in the callback in 1).

If that was possible, I think it would be awesome, I think that could simplify things a lot. Still, if I understand things correctly, we still could not revert the patch for bug 73375, even if we do that, as the sinks/sources would not be initialized at that point, but in init_profile.

Does that make sense at all?

Rough outline of new suggested startup order:

 1) Above the add_profiles call in module-alsa-card.c, we should first start listening to mixer events (in order not to get a race condition).
 2) Update availability of all jacks. This might require some refactoring of code as the jacks do not have associated ports at that point.

 3) add_profiles ends up calling alsa-mixer.c:device_port_alsa_init. Here, add a call to pa_device_port_new_data_set_available() and fill it in accordingly. This will also require refactoring the jack availability to port availability logic into a separate function in alsa-mixer.c.

 4) We add a new hook in module-switch-on-port-available that listens to pa_card_new. From this hook, we switch the suggested profile in case the current profile has no available ports (and we find another profile that has).

Does that make sense? Anything (or all) of the above that you'd like to write yourself?

what happen when user just use vga and don`t use hdmi ?

user may plugged headphone after pulseaudio completely startup

> 
> What about letting 1) and 2) to finish, as if everything went fine and then,
> as a last and desperate attempt to avoid having a profile with no ports
> available, check if there's a better option and switch profiles if needed?
> 

the source already has a profile with no port available

Ports:
		analog-input-mic: Microphone (priority: 8700, not available)
	Active Port: analog-input-mic
	Formats:
		pcm

(In reply to Raymond from comment #20)
> > 
> > What about letting 1) and 2) to finish, as if everything went fine and then,
> > as a last and desperate attempt to avoid having a profile with no ports
> > available, check if there's a better option and switch profiles if needed?
> > 
> 
> the source already has a profile with no port available
> 
> Ports:
> 		analog-input-mic: Microphone (priority: 8700, not available)
> 	Active Port: analog-input-mic
> 	Formats:
> 		pcm

Yes, and in that case my approach would be not to change a thing: only if you preselect a profile with no ports available when there are another profile with ports available.

But as David said, that's a hack and not the proper solution.

(In reply to David Henningsson from comment #18)
> Rough outline of new suggested startup order:
> [...]

Thanks for this outline, David. At a first glance it all looks like it makes sense to me, but still my knowledge on this is quite limited, so it's hard to make an informed opinion now on whether it really makes sense or not, or whether there are things I could write myself or not.

What I can say now, however, is that I'll try to take a closer look to this suggestion (ideally next week) by trying to implement it myself. Once I devote some time to that, I should be able to know better what exactly I'll be able to tackle and what not, and then I will surely have more questions too.

Of course, feel free to point out/comment anything you want in the meanwhile. I'm sure that any extra info you, or anyone else, can provide on this will be very valuable to me.

did you find any of those message in system log when you use debug version of alsa driver ?


+	snd_printdd("Headset jack set to iPhone-style headset mode.\n");
+}
+

+/* 
+	snd_printdd("Headset jack set to Nokia-style headset mode.\n");
+}
+



+	snd_printdd("Headset jack detected iPhone-style headset: %s\n",
+		    is_ctia ? "yes" : "no");
+	spec->current_headset_type = is_ctia ? ALC_HEADSET_TYPE_CTIA : ALC_HEADSET_TYPE_OMTP;
+}
+

(In reply to Mario Sanchez Prada from comment #21)
> (In reply to Raymond from comment #20)
> > > 
> > > What about letting 1) and 2) to finish, as if everything went fine and then,
> > > as a last and desperate attempt to avoid having a profile with no ports
> > > available, check if there's a better option and switch profiles if needed?
> > > 
> > 
> > the source already has a profile with no port available
> > 
> > Ports:
> > 		analog-input-mic: Microphone (priority: 8700, not available)
> > 	Active Port: analog-input-mic
> > 	Formats:
> > 		pcm
> 
> Yes, and in that case my approach would be not to change a thing: only if
> you preselect a profile with no ports available when there are another
> profile with ports available.
> 
> But as David said, that's a hack and not the proper solution.

it contradict the logic of module-switch-on-port-available which switch to other available /unknown port when active port is unavailable

when pulseaudio cannot find valid profile of the sound card, auto null is automically selected when there is no sound card available

(In reply to Raymond from comment #23)
> did you find any of those message in system log when you use debug version
> of alsa driver ?

I don't think I was running the debug version of the driver, nor I'm sure how I can do that. Would you mind sharing a few tips on how to do it so?

I've checked http://www.alsa-project.org/main/index.php/Help_To_Debug and a few more places, but still is not clear to me.

it is strange that mixer output different from codec info

neither alsactl init nor pulseaudio turn this switch on


Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]


Node 0x04 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP
  Control: name="HDMI/DP,pcm=3 Jack", index=0, device=0
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="ELD", index=0, device=3
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x09000094: OUT Detect HBR HDMI DP
  Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D3
  Power: setting=D0, actual=D0
  Connection: 2
     0x02* 0x03

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths/iec958-stereo-output.conf

[Element IEC958]
switch = mute

it is an element in iec958  conf but your barebone only have hdmi device and no digital device

those hdmi-output conf does not has this element 

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths

it bug of pulseaudio if those iec958 playback is mute switch of hdmi 

restore card device expect to restore volume/mute but pulseaudio did not save any info into the databse


D: [pulseaudio] alsa-mixer.c: Probing path 'hdmi-output-0'
D: [pulseaudio] alsa-mixer.c: Probe of jack 'HDMI/DP,pcm=3 Jack' succeeded (found!)
D: [pulseaudio] alsa-mixer.c: Available mixer paths (after tidying):
D: [pulseaudio] alsa-mixer.c: Path Set 0x83a26a0, direction=1
D: [pulseaudio] alsa-mixer.c: Path hdmi-output-0 (HDMI / DisplayPort), direction=1, priority=59, probed=yes, supported=yes, has_mute=no, has_volume=no, has_dB=no, min_volume=0, max_volume=0, min_dB=inf, max_dB=-inf
D: [pulseaudio] alsa-mixer.c: Jack HDMI/DP,pcm=3, alsa_name='HDMI/DP,pcm=3 Jack', detection possible

(In reply to Mario Sanchez Prada from comment #22)
> Thanks for this outline, David. At a first glance it all looks like it makes
> sense to me, but still my knowledge on this is quite limited, so it's hard
> to make an informed opinion now on whether it really makes sense or not, or
> whether there are things I could write myself or not.
> 
> What I can say now, however, is that I'll try to take a closer look to this
> suggestion (ideally next week) by trying to implement it myself. Once I
> devote some time to that, I should be able to know better what exactly I'll
> be able to tackle and what not, and then I will surely have more questions
> too.

I'm so sorry for having taken so long to finally get back to this, but the last months it was nearly impossible to me to devote time to sit down and work on upstreaming this patch.

Fortunately, Arun lend me a hand during the Gstreamer hackfest and I'm happy to say that I have a version of the patch that I hope will be on the right path. Just sent it to the mailing list for review now:

http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023420.html

The idea implemented is based on David's suggestion from comment #18 after "digesting" it with the help of Arun, but perhaps with a few twists I found as needed while writing the actual patch. Hope it looks ok anyway, though :)

seem driver bug 

only HP pin but no speaker


!Sysfs Files
!!-----------

/sys/class/sound/hwC0D0/init_pin_configs:
0x12 0x40000000
0x14 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x411111f0
0x1a 0x411111f0
0x1b 0x411111f0
0x1d 0x40541a05
0x1e 0x411111f0
0x21 0x04211010

/sys/class/sound/hwC0D0/driver_pin_configs:
0x19 0x04a110f0

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/79.